You are on page 1of 111

Mrina l K.

Roy

Introducing Advanced ATP


{aATP) in SAP S/4HANA®

~ Rheinwerk
Pub ishing
What You'll Learn

In this E-Bite, you'll discover how advanced available-to-promise (aATP) in


SAP S/4HANA helps meet demand for your product. You'll learn about the
features and SAP Fiori apps that are available for key aATP processes: prod-
uct availability check, product allocation, alternative-based confirmation,
backorder processing, and release for delivery. Finish with a look ahead at
potential aATP innovations and migration tips!

1 Available-to-Promise Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 ATP in a Supply Chain ........... . ..................... . ... . 7
1.2 Available-to-Promise with SAP ... . .... . ...... . .... . .... . ... . 8
2 Product Availability Check .................................... . 17
2.1 What Is Product Availability Check? .......... . ........... . . . 17
2.2 Configuration Basics ...................................... . 20
3 Product Allocation ........ .... ............. ...... ............ . 26
3.1 What Is Product Allocation? ............................... . 26
3.2 Combining Product Allocation and Product Availability
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Basic Configuration for Sa les Order . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Basic Configuration for Stock Transport Order............... 35
3.5 SAP Fiori Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Alternative-Based Confirmation ............................... . 52
4.1 What Is Alternative-Based Confirmation? ........ .. ........ . 53
4.2 SAP Fiori Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Combining Alternative-Based Confirmation and Product
Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Limitations and Expected Enhancements . . . . . . . . . . . . . . . . . . . 59
5 Backorder Processing .... ........ ........... ....... ........... . 61
5.1 What Is Backorder Processing? ............................. . 62
5.2 Configuration Basics ............ . ......................... . 64
5.3 SAP Fiori Applications . .. ... . .... . .... . . . .... . .... . .... . ... . 65

4
5.4 Globa I Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5 Fall back Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6 Combining Backorder Processing with Product Allocation . . . 90
6 What Is Release for Delivery? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.1 SAP Fiori Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2 Combining Release for Delivery with Product Allocation . . . . . 101
6.3 Combining Release for Delivery with Alternative-Based
Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7 What 's Ahead for aATP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8 Migration at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


9 What 's Next ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

1 Available-to-Promise Basics
Available-to-promise (ATP) is the uncommitted portion of a company's
inventory and planned production, used to support order promising for
customer orders. The ATP quantity is very different from the available stock
quantity. For example, perhaps there are 100 total pieces of stock for a prod-
uct, but 80 pieces have already been committed to some sales orders or
internal production. In that situation, the ATP quantity is only 20 pieces,
which can be promised to new sales orders or new requirements.

Order promising generally considers other business parameters in addition


to ATP quantity. Suppose a sales order comes from an ordinary customer for
20 pieces when the ATP quantity is 20; thus the sales order gets confirmed.
The ATP quantity then becomes zero; if another sales order is received later
for the same product, then that sales order can't be promised or confirmed.
If this customer (whose order is received later) is a premium customer offer-
ing a high price with good payment terms, then it may be more strategic
(from a business perspective) to prioritize the sales order from the premium
customer over that of the ordinary customer.

s
1 Available-to-Promise Basics

ATP quantity is defined as follo\<VS:

ATP quantity= Stock+ Receipts - Committed requirements


The receipts can be purchase orders or planned orders, and committed
requirements can be sales o rders, deliveries, reservations, and the like.

Figure 1.1 sho\ivs the calculation process for ATP quantity and some import-
ant business considerations for prioritizat ion in product availability checks.

Customer order
Prioritization
ATP quantity ,
' parameters
Stock ATP Price
+ Purchase order

~
Payment t erms
+ Planned order
- Sales order (commit ted}
- -- Priority
Service level
- Delivery
Loyalty
- Reservations
Yes No History of return
,
'
Order promised Order not promised

Available-to-promise (ATP)

Figure 1.1 ATP Quantity and Business Considerations for Product Availability Checks

If an order can't be promised for the requested quantity on the requested


delivery date for a given product in a particular plant or warehouse, then
other alternatives that may be considered include the following:

• Replenish stock from anoth er plant


If a product's availability is checked in, say, the Munich plant and it isn't
available, then the same product's availability can be checked in, for
example, another plant located in Frankfurt or another nearby location. If
available, then the requisite quantity of the material can be transferred
from the Frankfurt to the Munich plant.
• Substitute the order with anoth er similar produ ct
If a customer wants to buy an iPhone XS 32 GB Black, an alternative product,
such as an iPhone XS 32 GB Gold, can be offered to the customer instead.

6
1 Available-to-Promise Basics

ATP is a response to a customer's request for the availability of product; no


manufacturer (or seller) wants to lose a customer due to nonavailability of
products in today's competitive market. In the following sections, we'll
evaluate the importance of promising to fulfill and committing to a cus-
tomer order with multiple sellers and customers in a typical supply chain
scenario, as well as review the ATP solutions provided by SAP.

1.1 ATP in a Supply Chain


ATP is one of the most critical business functions for all sellers in a supply
chain, as depicted in Figure 1.2. There are financial impacts (apart from loss
of goodwill, credibility, etc.) if a sales order from a customer can't be prom-
ised on the requested delivery date or if there are missing parts during the
assembly of finished goods (roller bearing, pump, etc.) in the production
line, which can result in further delays in the delivery, down the line in sup-
ply chain. However, no manufacturer or seller also wants to keep exces-
sively high inventory levels (requiring higher working capital) to avoid
stockouts.

In addition, note the impact of nonconfirmation of an order (or delay in


delivery) in a supply chain scenario. If there is a delay in delivery of roller
bearings to a pump manufacturer for the supply chain scenario in Figure 1.2,
for example, it may affect the delivery schedule of the pump to the power
plant, resulting in a possible delay in the power plant's installation-com-
missioning schedule.

An organization's ATP situation is highly dynamic (i.e., it changes quickly),


so up-to-date information on ATP is crucial for every manufacturer/seller in
the supply chain. Availability of the right product with the right quality at
the right time at the right place is the aim in every step of the supply chain.

A manufacturer or seller generally has several customers. For example, the


car manufacturer in Figure 1.2 has customers A, B, and C. If the demand is
higher than the production capacity, then the prioritization parameters

7
1 Available-to-Promise Basics

need to be considered to choose a customer and the order quantity that


should be promised to the customer.

In recent years, customers' demand has become unpredictable, and there is


an increasing pressure to keep the stock as low as possible. This unpredict-
able demand and the need for lower stock levels calls for efficient ATP capa-
bilities across all parts of today's complex supply chain .

.
- Customer A

,...., : Customer B
~ Car ....._
: ; Customer C

, , ,.•
Steel - Roller bearing - Pump
I - Power Plant


* ATP ~ Fan
1
Figure 1.2 ATP f or Sellers in Supply Chai n

1.2 Available-to-Promise with SAP

ATP check functionality in SAP software is robust and provides extensive


capabilities. SAP solutions with availability checks have also evolved over
time to cater to the increasingly complex requirements in order promising
in today's industry or supply chain.

The concept of classic ATP remains the same in all SAP solutions and can be
executed in transaction objects like sales orders (including delivery), stock
transport orders, production orders, and project networks, using the same
formula for calculation of ATP quantity:

ATP quantity= Stock+ Planned receipts - Planned issues

However, current solutions provide very advanced features for ATP checks
(i.e., beyond classic ATP). The new ATP solution in SAP S/4HANA is called
advanced available-to-promise (aATP), introduced in the 1610 release.

8
1 Available-to-Promise Basics

Currently, SAP has three primary ATP solutions:

• Classic ATP check in SAP ERP and SAP S/4HANA


• Classic ATP check in SAP ERP in combination with global available-to-
promise (GATP), part of SAP Advanced Planning and Optimization (SAP
APO)
• SAP S/4HANA for advanced ATP

In common parlance, ATP and product availability check are often used
interchangeably.

Note
SAP APO has four modules: Demand Planning (DP), Supply Network Planning
(SNP), GATP, and Production Planning and Detailed Scheduling (PP-DS). Table 1.1
describes these modu les and their main features.

Demand Planning (DP) Supply Network Planning (SNP)


• Advanced demand ma nagement • Cross-plant plann ing for supply
and forecasting methods chain network
• Easy aggregation and disaggrega- • Rough-cut planning to be detai led
tion through PP/DS
• Macro functiona lity for quick and • Advanced planning algorithms
user-friendly computations
Global ATP (GATP) Production Planning and Detailed
Scheduling (PP/DS)
• Location and product substitution • Plans material and capacity simul-
• Multilevel ATP (MATP) taneously

• Capabil ity-to-prom ise (CTP) • Finite capacity planning

• Backorder processing • Advanced scheduling algorithms

Table 1.1 Functionalities of SAPAPO Modules

In the following sections, we'll first discuss the similarities among the three
solutions and then discuss where their functionality differs.

9
1 Available-to-Promise Basics

Similarities in Solutions for Availability Check


Classic ATP is executed at the time of sales order and delivery processing in
all three solutions (SAP ERP, SAP ERP with GATP, and SAP S/4HANA), as
depicted in Figure 1.3.

SAP ERP
Order
Sales order 1-+< confirmation._ Delivery Goods issue

SAP ERP
Order
Sales order Delivery Goods issue
confirmation
'
- -
Sales order - ATP GATP Delivery - ATP

SAPS/4HANA
Order
Sales order i--+< confi rmation~ Delivery ~< Goods issue

Figure 1.3 Execution of Classic ATPfor Sales Order and Delivery Processing

In addition to product availability check, all three ATP solutions also pro-
vide features, including the following:

• Product allocation
This is a mechanism to avoid "first come, first served" problems in order
management.
• Backorder processing
This is a re-ATP process (i.e., carrying out ATP after initial order creation)
to confirm high-priority orders and unconfirm low-priority orders.
Both product allocation and backorder processing are available in SAP ERP,
SAP APO GATP, and aATP. GATP provides very advanced features for prod-
uct allocation and backorder processing when used with SAP ERP. aATP has

10
1 Available-to-Promise Basics

an entirely new design for product allocation and backorder processing


with its SAP Fiori apps and is easier (and more flexible) to set up than the
complex GATP. Product allocation and backorder processing with aATP will
be discussed in detail in Section 3 and Section 5, respectively.

Figure 1.4 shows the process flow for a sales order entry, along with its logis-
tic execution; this typical process flow is applicable for all three ATP solu-
tions with advanced features like product allocation and backorder pro-
cessing.

Sa les Order management Warehouse and


..,A., distribution

~ )
... · 1_ ,
Sales order entry A• Product allocation
.......~
Backorder
processing
J._
Sa les order ,
confirmation Delivery processing
t
Transport

* ATP ~ Influences

Figure 1.4 Process Flow for Sales Order and Logistic Execution

Differences in Solutions for ATP Checks


ATP checks in SAP ERP have some shortcomings; hence, many customers
have implemented SAP APO to use the advanced ATP functionalities of
GATP. However, SAP APO requires additional investment and maintenance
because it's a separate SAP application. aATP in SAP S/4HANA is embed-
ded in the SAP S/4HANA core (i.e., no separate application is needed),
allowing the same master and transaction data to be used within the SAP
S/4HANA core (i.e., no need to transfer master/transaction data through

11
1 Available-to-Promise Basics

an interface). It has a completely new design setup using easy and simple
business terms with SAP Fiori apps.

Figure 1.5 depicts the differences in ATP solution setup (configurations,


master data, and transaction data) in SAP ERP, GATP, and aATP.

SAP ERP GATP

Customizing - Customizing

Master data - Master data

Transaction data - Tra nsact ion data

SAP ERP

( Custom izing J [ Mast er data ) [ Transaction data J

SAPS/4HANA

[ Customizing
J ( Mast er data
J
( ) ( Transaction data )
Figure 1.5 Solution Setup for Product Availability Checks in SAP ERP, GATP,
and aATP in SAP S/4HANA

Salient differences in the setup and functionalities of ATP checks in SAP


ERP, GATP, and aATP in SAP S/4HANA are highlighted in Table 1.2.

12
1 Available-to-Promise Basics

Functionality/ ATP in SAP ERP GATP aATP in


Feature SAPS/4HANA
Configuration, Configurations are Configurations are Most of the set-
master data, and done in the Im pie- done in both SAP tings are estab-
transaction data mentation Guide ERP and SAP APO. lished via SAP Fiori
(IMG), and all mas- Configurations and apps. Configura-
ter data and trans- master data are tions, master data,
action data reside transferred from and transaction
in the same appli- SAP ERP to SAP APO data reside in the
cation (SAP ERP). (unidirectional). same application
Transfer of trans- SAP S/4HANA.
action data is
bidirectional.
Synchronization
of the two systems
(SAP ERP and SAP
APO) is a major
challenge and
needs continuous
monitoring.
Complexity in Configurations are Configurations are Configuration is
design and main- simpler than GATP. complex. less technical and
tenance very much simpli-
fied with fewer set-
tings and intuitive
SAP Fiori apps.
Performance Not good. Needs improve- Performance is
ment. significantly faster
w ith the SAP HANA
database and sim-
plified data model.

Table 1.2 Differences in Prod uct Availability Checks in SAP ERP, GATP in SAP APO, and aATP
in SAPS/4HANA

13
1 Available-to-Promise Basics

Functionality/ ATP in SAP ERP GATP aATP in


Feature SAPS/4HANA
Product a !location Al location data is Allocation data is Allocation data is
stored in tables, stored in sepa rate stored in separate
often resulting in tables and Info- tables. There is no
locking of users. Cubes. The check need to mainta in
The check date can date can be the info structures. The
on ly be the mate- material availabil- check date can be
rial availability ity date, goods the requested
date. Product aIlo- issue date, or deliv- delivery date,
cation data is set at ery date. Pia nt- goods issue date,
basic data of mate- specific use of or material ava il -
rial master and product aIlocation ability date. Mate-
valid for all plants. is a sta ndard func- rial master does
Product allocation tion. Product allo- not need any
not supported for cation is supported update for product
stock transport for stock transport allocation. Switch-
order. order. ing off product
allocation doesn't
require any change
in master data.
Product allocation
in stock transport
order is supported
from the 1709
release.

Table 1.2 Differences in Product Availability Checks in SAP ERP, GATP in SAP APO, and aATP
in SAPS/4HANA (Cont.)

14
1 Available-to-Promise Basics

Functionality/ ATP in SAP ERP GATP aATP in


Feature SAPS/4HANA
Backorder Offers backorder Offers more flexi- Completely new
processing processing with bility with filter- design and simpli-
Ii m ited ca pa bi I ities ing, sorting, and fied, set up with
(few filter and sort simulation capa- five new confirma-
fields}. bility. tion strat egies.
Redistribution not Red istribution pos- Redistribution pos-
possible. sible. sible with more
No possibility to Possible to improve flexible confirma-
preserve prev1- with no reduction tion strategies.
ously confirmed of previously con- The gain strategy
quantity. f irmed quantities.
.
ensures previous
confirmations with
possibility of gain
(improvement).
Provides auto-
matic fa ll back
capability for
except ions.
Location and prod- ATP in SAP ERP can Location su bstitu- Location substitu-
uct substitution check avai labil ity tion offers the tion has been
functionality on ly at a single option to check introduced with
plant or location availability at mul- a new solution
for a line item, and tiple plants/loca- known as alterna-
can't switch to tions automatically tive-based confir-
another plant based on preset mat ion (ABC} in the
aut omatically. business rules. 1809 release.
Product substitu- Product can be Product substitu-
tion possible on ly substituted auto- tion (on the same
manually. matically from a ABC framework) is
defined list of expected in the
products. SAPS/4HANA
release slated for
2020.

Table 1.2 Differences in Product Availability Checks in SAP ERP, GATP in SAP APO, and aATP
in SAP S/4HANA (Cont.)

15
1 Available-to-Promise Basics

Functionality/ ATP in SAP ERP GATP aATP in


Feature SAPS/4HANA
Creation of trans- Configurations Some ATP configu- There are a few IMG
port request are generally first rations are trans- configurations that
created in the ferred from SAP create t ransport
development envi- ERP to SAP APO requests. However,
ronment, which through the core most of the settings
creates a transport interface, and addi- for product alloca-
request ; the trans- tional configura- tion, backorder pro-
port request is tions are created in cessing, and release
subsequently SAP APO, which for delivery are
transported to the creates transport done through rele-
quality and pro- requests. Su bse- vant SAP Fiori apps
duction environ- quently, the trans- that don't create
ments. port requests are transport requests.
transported to the These settings can
quality and produc- be regarded as mas-
tion environments. ter data.
Business users can
also set up aATP
using intu itive SAP
Fiori apps (which is
a major benefit of
aATP).
Deployment option On -premise. On-premise/ On-premise/cloud.
SAP HANA Enter-
prise Cloud.
User interface SAP GUl/SAPUIS. SAP GUI. SAP Fiori.

Table 1.2 Differences in Product Availability Checks in SAP ERP, GATP in SAP APO, and aATP
in SAP S/4HANA (Cont.)

Note
aATP was introduced in the 1610 release of SAP S/4HANA. Functionalities/
features in aATP are evolving and will continue to be developed and enhanced
in the new few years. SAP has plans to provide the same/sim ilar system capabil-
ities in aATP as in GATP of SAP APO. SAP declared in SAP Note 2456834 that
GATP w ill be succeeded by aATP in SAP S/4HANA. See Section 7 for upcoming
features and SAP's roadmap for aATP in SAP S/4HANA.

16
2 Product Ava ilability Check

2 Product Availability Check


Product availability check is one of the key business functions of order-to-
cash or typical supply chain scenarios. It checks whether the requested
material is available in the required quantity on the requested date for spe-
cific requirements (sales order, production order, etc.). In the following sec-
tions, we'll walk you through the product availability check process and dis-
cuss the basics of product availability check configuration.

2.1 What Is Product Availability Check?


Product availability check is one of three ATP methods, as shown in Figure 2.1:

• Product availability check


Availability of a product (material) is checked with below formula:
ATP quantity = Available stock+ Planned receipts - Planned require-
ments

If the ATP quantity is positive, then the order is confirmed.


If the availability check is supposed to consider the replenishment lead
time, then the order is confirmed after the replenishment lead time, even
if the stock is currently not available. Replenishment lead t ime is the time
to produce or procure an item.

Note
ATP and product ava ilability check are often used interchangeably. ATP includes
product avai lability check and other methods like product allocat ion.

• Product allocation
When the demand is more than the supply, product allocation restricts
the "first come, first served" method of order confirmation- that is, it
avoids the full confirmation of scarce products to initial orders so that all
customers can be allocated specific quantities based on business strategy
(discussed in detail in Section 3).

17
2 Product Ava ilability Check

• Alternative-based confirmation
This is another variant of ATP. An availability check is carried out at the
ordering plant, and if the material isn't available to be promised in that
plant, then the system can check its availability in other plants and con-
firm the order, if available.

Note
Alternative-based confi rmation {ABC) is the successor of rules-based ATP (RBA)
of GATP in SAP APO. Functionalities in ABC are similar to RBA, but not the same.
ABC functionality will be discussed in Section 4.

ATP

Product availability Product Alternative-based


check allocation confirmation
'

With replenishment Without replenishment Successor of RBA of


lead time lead time SAPAPOGATP

Figure 2.1 Product Availability Check in aATP

Now let's discuss how product availability check is carried out. Customers
generally indicate the date on which they require a material to be delivered
at their sites (plants/warehouses). Hence, a sales order captures the re-
quested delivery date for the customer with the requested material and
quantity.
In SAP (SAP ERP, SAP APO GATP, or aATP), product availability check is
always carried out on the material availability date at a specific plant (ware-
house). Determination of material availability date and ATP quantity is illus-
trated in Figure 2.2. Material availability date is calculated backward from the
requested delivery date using the following formula:

18
2 Product Ava ilability Check

Material availability date= Requested delivery date - Transportation time -


Loading time - Pick and pack time

Product availability check is carried out on a specific date (or time axis)
using the following formula:
ATP quantity= Available stock+ {Planned receipts (Purchase requisition +
Purchase order+ Planned order)]-[Planned issues {Sales order+ Delivery+
Reservation)]

Material Loading Goods Requested


availability date date issue date delivery date
,
/
/ '' '' '' Transport ''
' '
Sales order
'----~----'/ /
/
'
'
'
'
Loading .' '
'
/
'' Pick/Pack
' ' ''
/ ' ' Time
¥ ' ' ' '

ATP
No
' '
' '
Yes '
Sales order
confirmed "'C ,,.
QI '5.
c: ·-
Business c: QI
111 v
Available Pu rchase Purchase Planned
strat egy • a: ~ stock order requ isition order
How . ..
How much Yes "'C ,,.
QI QI Sales Delivery Reservation
When c: ::I
c: ,,. order
111 ,,.
Yes a: - I I

No

Figure 2 .2 ATP Check and Order Confirmations i n Sa les Order

An order gets confirmed (or promised} if the calculated ATP quantity is


greater than or equal to the requested order quantity. If the order isn't con-
firmed, then the big questions (how, when, how much, etc.) of fulfilling the
customers' requirements need to be ascertained or evaluated. It's a business

19
2 Product Ava ilability Check

strategy to decide which customer's order should be prioritized based on


price, promotion, payment terms, service level, and so on for situations in
which demand is greater than the supply.

As of the SAP S/4HANA 1809 release, product availability check is carried


out with SAP GUI Transaction C009 (like in SAP ERP; following SAP menu
path Logistics • Materials Management • Inventory Management • Environ-
ment• Stock• Availability Overview).

Note
PACs also can be carried out through other SAP GUI transactions, such as Trans-
actions VA01/VA02, ME21N/ME22N, and so on, during creation/ change of sales
order or purchase order. Product availability check also works with project stock,
production order, and more, and can be checked through Transaction CJ20N,
Transaction C002, et c.

2.2 Configuration Basics

There are certain prerequisites (configurations and master data) for the
product availability check to take place with aATP for a sales order, as fol-
lows:

• The availability check group must be active for aATP to work (as shown in
Figure 2.3, 0 ).
• The availability check group must be set in the Sales: General/Plant view
of the material master of the sales order (as shown in Figure 2.3, 8 ).
• The requirement class and schedule line category must be activated for
Availability check (as discussed later in this section).

20
2 Product Availability Check

~ New Entries [t) ~ tl?) ~~G

Av ,..Descrtitlon .,Total5ales TotoM\eqs Bl:xk Qtl\Q


...,
NO check Acct.m ... RelChkPlan Advanced ATP
NC .._
NO PAC ched<I 0
SP Stock and Plan. Re_A A Q) 0 3
SR Stock and Rel. Rec. A A ~ 0 3
ST Consider Only StockA A ~ 0 A Acc.ive
Yl Individ.requiremen_,A A ~ 0 3 A Active
Y2 Jnd.Req.chng.Che .. A A 2) 0 3 A Act.ive
Y3 Only ATP ro PAL A A ~ 0 3 A Active

~ Display Material FGJ. 5 {Finish ed Product)


¢ Additional Data ~ Org. Levels

• Sales: General/Plant • Foreign trade export

Material ~f-Gl_S~~~~~~~~~~---.fffi
Oescr. TFG AA TP Test 15
f:lant I1010' Plant 1 DE

General data
Base Um of Mea,...re fST"' Piece Replacement Part l
Gross weight f0,5oO KG Qual.f.FreeGoodsDis.
Material fre;;iht grp
r
,_,~----.]
t Jo,4so
· ~~~.....;.;;.:.;;;;.;~~~....;....
t
Availabiity check Y3 Only ATP no PAL
Appr.batch rec req. l
Batch management 0

Figure 2.3 Configuration of Availability Check Group and Its Setup in Material Master

In the following sections, we'll discuss how to configure relevant configura-


tion objects: availability check group, checking rule, product availability
check control, and requirement type/class.

Note
Configurations for product availability check in aATP are the same (or similar) to
product availabi lity check in SAP ERP and are carried out in the IMG menu path
(i.e., not in SAP Fiori apps).

21
2 Product Availability Check

Availability Check Group


Availability check group is configured under the IMG menu path Cross-
Application Components • Advanced Avai lable-to-Promise (aATP) • Product
Ava ilability Check (PAC) • Define Avai lability Check Group.

Note
The ava ilability check group also can be set as the defa ult at t he material type
and plant levels via t he IMG menu path Cross-Application Components •
Advanced Available-to-Promise (aATP} • Product Availability Check (PAC} • Con-
figure Defa ult Values for Availability Check Group. However, the system priori-
t izes the value if it's set in the material master.

Checking Rule
The checking rule specifies the scope for the availability check for specific
transactions. The system has predefined checking rules for sales and distri-
bution and for logistics execution (delivery, goods issue), as listed in Table 2.1.

Scenario Business Transaction Checking Rule


Ma ke-to-stock (MTS) Sales order A
MTS Delivery B
Make-to-order (MTO) Sales order AE
MTO Delivery BE
MTS, MTO, Engineer-to-order (ETO) Goods issue 03

Table 2.1 Checking Rules in Sales Order and Logistics Execution

Scope of Availability Check


The checking group and checking rule determine the scope of availability
check, as shown in Figure 2.4. It controls the availability check for specific
transactions (based on the checking rule) and decides which specific objects
(or parameters) should be considered for the availability check (for instance,
stocks 0 , document types f), replenishment lead tim e e. and storage loca-
tio n level 0 ).

22
2 Product Ava ilability Check

Checking group
Checking rule
(ava ilabi lity check)

Availabil ity check con trol


(scope of check)

Ch.inge View "A v.ill.iblllty Check Cont r ol": Det .ills


~ New Entries tD §, 12' ~ [} ~

AYaBabitity check lv31Only ATP no PAL


Ched<lng rule [Al sales order
OlR• Description of Checking Rule
01 Checking rule Ol Stocks 0 ~ J In}ovtward movements 8
03 Goods Issue 0 Include safety stock I 'rx ~.Pl.l'chase Ordets
A sales Order O stocklnTransfer 0 Incl. purch.r_.ISltlons
ME. SO order; make-to-order stock O lncl.quality insp. stock O rncl. dependent reqs
AQ SO order; project stock 0 Incl. blocked stock Rllncluefe reservations
AV SO order; re tt.l'nable packaging 0 Inc:I. restricted-use stCK.k Rllnclude sales reqmts
AW
B
SO order;
Delivery
conslgrwnent O w/ o slbcontractno
_J RlW!th Deiverv Note
0 Incl.ship .notiflcat .
BE
BO
BQ
SO delivery; make·t i>crder stock
Backorder processing
SO delivery; proj ect st ock
Replenishment lead time
[;1)Chack without RlT e 1 Incl.rel.order
lncl.depen.reservat.
reqs
0 Do not check
'""l Do not check
BV so delivery; returnable packaging storaoe hx:atiOn inspectie:ln Incl. planned orders n Do not check
BW
PM
SO delivery; consigrwnent
ChecklnQ rule for plant matitenance
0 No stor.loc. inspectn O j With Prod.cuon o rders l ] ronore

pp PP checking rule Misshg parts processing


PS PS Checking rule (project system) Chackhg period: GR I]
RP Replenishment
RS CheckinQ rule (SAP Retail Store) Receipts in past 0 Include receipts from past and future
so Order check.rule (CRT)
SP Order check.rule (REL)

Figure 2.4 Determination for Scope of Availability Check

Requirement Type/Class and Schedule Line Category


Availability check fo r requirement class (determined through requirement
type) and schedule line category must be activated, as shown in Figure 2.5,
for the availability check in a sales order.

The Ava il. Check flag is present in both requiremen t class and schedule line
category, and must be active for a product availability check in the sales
order. If Ava ila bility is flagged in the schedule line category but not the
requirement class, then the availability check will not take place in the sales

23
2 Product Availability Check

order. The requirement class is a higher-level object, and the flag on the
schedule line category provides t he opt ion to switch off the availability
check in certain scenarios, if it isn't needed. The availability check for the
schedule line category works in the sales order only if it's also activated for
the requirement class of the sales order.

Chilnge St.Jnd.Jrd Order 119: Overview


60" fclP ..... .t:l ~ <§J D (ill] Orders E ti<0oc..-nent

Standard Order
Sdcl-TQ Parll:
1119
l lOOOOS6
l
I
N~I V.._,,,
Premum custcmer t 0-11123 M\!rlch
l 990,00 ' tUR
0

d
r
stm.To paty 1000056 Ql Io.• •" '
Cust. Reference IMlJ! ICust . Ref. Date 126 . 07. 20111
~
~ Item overview Item detal Orderng paity .)' PrOCU'ement v SliiJlli"1o Reasoo ftlr rejection

~~ ~ ~~ Iii GtlM> l
terns
I Item Material ~ COnfirmed Qty SU Mat.Av.Ot. SLC.. RqTy
10 FGlS 1010 OEA 03 . 08 . 2017 ZP 04Z
9EA 0,, 17 ZP

Chilnge View "Millntilln Schedule Line Ciltegorl ''._eta/ls Chilnge View ' lequlrements Cl.Jsses": Det.Jlls
~ Now Entr1es ID ~ ~ ~[}~ ~ Now Entries ID ~ ~ ~[}~

SChed.lne cat. ZP
~
o ~DAO I
-~ Reqnts class 042] corde!Lclehe<u:e qml ~
-.....c1ai.
"' R~ements
Deivery block fl Asserrllly
Movement type 1•011 GO Qoods lssue:delvy If Item rel.f.dv. IAval. Check NJ I Asserrllly type
0
Movement Type l·Step n REQ. trMlSfer NJ Order costing 0
Drdor Two r:::J Q P.roq.del.schcd Allocation Ind. 0 Automatic "*'19 0
Item cateq:iry [] 0 Ext.capa. i:mrtig Prod.-•tlon 0 S!Jeclal Stod: r
Acct ASSl1Tlt Cat [] lnd.req.recb:tn 0 Order Type D
~te Sched. l.iies [] No~te o~.Sched NoM\P n Ava.ca1icxnents 0
MvT 1'5. Val. SIT Cl
S!Jec.1,., WJ. Sil .0
Tr.nsaction lk>w
u'ICOR"Qi.!>'OCed. [301 General Sched. Lhe
~Req.{Assernbly
1 1;/)Avallabllty
0 Prod.-atlcn
I
Figure 2.5 Requirement Class and Schedule Line Category of Sales Order Activated for Avail·
ability Check

Figure 2.6 shows the determination of the requirement class and schedule
line category with relevant values from the material mast er and sales order.

24
2 Product Availability Check

Is strategy group Yes


maint ained in
material master?

No Strategy Main strategy

Is MRP group Yes


maint ained in
material master?
Requirement Requirement
.--- type cl ass
No
Item category
-- - -.
(sales order) '
'
'
'

MRPtype
(material master)
--. Schedule line
category

Figure 2.6 Determination of Requirement Class and Schedule Line Category and Their
Influence on ATP

Note
The product availability check of aATP also works for transaction objects other
than sales orders, like production orders, project networks, and stock transport
orders. The releva nt order types need to be set f or an availability check in the
IMG menu path Cross-Application Components• Advanced Available-to-Prom-
ise (aATP) •Configuration Activities for Specific Document Types• Planned and
Production Orders • Configure Scope of Availability Check for Production and
Process Orders.

The checking rule for production (or project network) can be created (i.e., not
predefined by the system as in case of sa les orders and delivery) in the menu
path Production •Shop Floor Control •Operations •Availability Check • Define
Checking Rule.

25
3 Product Allocation

3 Product Allocation
Product allocation is used when the demand is more than the supply (or
capacity to produce). It avoids the "first come, first served" way of order
promising and ensures that each customer receives its allocated share-
that is, the customer who places an order first doesn't take all (or most) of
the product.
When the supply is limited, products may be allocated (shared) to be sold to
the following groups:
• Premium or strategic customers (customers with high price, lower return
rates, good payment terms/credit history, etc.)
• Target regions (e.g., if a product needs to penetrate certain markets to
beat competition or be promoted in an entirely new region)
In the following sections, we'll look at how product allocation works, how
product allocation and product availability check work together, how to
configure product allocation, its main SAP Fiori applications, and some
more advanced product allocation-related functionalities.

3.1 What Is Product Allocation?

Let's walk through a simple example to understand how product allocation


works. In a week, 100 units of a product are produced. The allocated quanti-
ties for different customers are shown in Table 3.1.

Customer A Customer B Customer C All Other


Customers
Allocated quantity 30 20 15 35
Requested order quantity 50 30 10 50
Confirmed quantity 30 20 10 40

Table 3.1 How Product Allocation Works

26
3 Product Allocation

We can see that the confirmed quantity is equal to either the allocated
quantity (customers A and B) or the requested order quantity (customer C,
fo r which the requested order quantity is less than the allocated quantity). If
the products are not allocated, then there's the chance of a specific cus-
tomer grabbing all or most of the products (which are in short supply);
therefore, product allocation prevents "first come, first served" behavior in
order fulfillment process.

Let's discuss some important components of product allocation. Note that


these components are also relevant for setting up product allocation in
GATP. However, settings for these components have been very much sim-
plified in aATP.

Characteristics
Characteristics are the matching fields (parameters) of a transaction object
(such as Sales Orga nization for a sales order) against which products are allo-
cated and order confirmations are carried out. M ateria l Group, shown in
Figure 3.1, is another example of a characteristic other than Sales Organiza-
tion.

Characteristics are created directly in an SAP Fiori app in aATP (unlike GATP,
in which characteristics are created in the IMG menu path). A user with the
SAP_BR_INTERNAL_SALES_REP role can configure characteristics in the Con-
figure Product Allocation SAP Fiori app, which we'll discuss further in the
Configure Product Allocation section.

As of release 1709, SAP S/4HANA provides product allocation functionality


with sales order as well as with stock transport order. Figure 3.1 shows
some of the standard characteristics for a sales order 0 and stock transport
order f).

Note
The SAP S/4HANA 1809 release also provides the option to use custom and
additiona l fields as characteristics for product allocation for both sales order
and stock transport order.

27
3 Product Allocation

0 Select Characteristics Select Characteristics

Show Additional Characteristics S Cl Show Additional Characteristics S Cl

Characteristic Characteristic

0 v Sales Document 0 v Stock Transport Order

0 Customer Group 0 Purchasing Group

0 Distribution Channel 0 Purchasing organization

0 Division 0 v Stock Transport Order Item

0 Sales District D v Stock Transport Order Shipping Data

D Sales group D Division

0 Sales office D Distribution Channel

0 > Business partners D Sales Organization

0 [ } ]Sales Organization 0 > Ship-to party

0 v Sales Document Item D Material Group

D Material Group 0 Requirement Segment

D Requirement Segment D Plant

D > Business partners

Figure 3.1 Standard Characteristics for Product Allocation for Sales Order and Stock Trans-
port Order

Collective Allocation
Collective allocations are used for scenarios in which the allocations are not
defined specifically for the characteristic value combination. Note that allo-
cations for customers A, B, and C are defined specifically. For example, in
Table 3.1, allocations for all other customers can be classified as collective
allocations-that is, the allocations for other customers (other than A, B,
and C) have not been specified individually but specified collectively.
aATP provides very easy and flexible options for maintaining collective
allocations, as shown in Figure 3.2 via the Configure Product Allocation app.
This app shows collective allocation for the characteristic value combination
Sales Organization, Sold-To Party, and Materia l Number managed by the sys-
tem and maintained manually. You can see the characteristic value combi-
nation (CVC) maintained automatically by the system on the top screen 0 ,
and the manual maintenance of the collective allocation on the bottom

28
3 Product Allocation

screen f). Note that the product allocation rows marked with# indicate col-
lective allocation.

Product Allocation Object v

PAL3 PALJ s.1.. Org Customor Materla4

sececuon Range:
12.03.2019. 27.05.2019 f3

Product Allocation Planning Data (4) 0 -


search C\ Add Change Sl<lrus Change constraint Status

Sales Organization Sole!-To Party • CU$1.. Material Number $Ylu$ ConstJaint Stat\!$ U .03.2019 18.03.2019 25.03.2019 01.04.2019
As in sequenc:e
0 Acl.Ne Con.st:raint 100 100 100 100
As in Sequence
D 1010 • Active Constraint 40 40 40 40
As in Sequence
0 1010 10100001 • Actii.te Constraint 20 20 20 20
Asln5eq~
Ql ActOle Constraint 10 10 10 10

Product Allocation Object v


Collective Alloc.ation Managed ..ianualty
No Collective Allocation

5eeecti0n Range:
12.03.2019. 27.05.2019 f3

Product Allocation Planning Data (2) f) search C\ Add Change Sl<lrus Change constraint Status

D Sil•• Organiz•tion Miterial Number I sY•.. Cons.traint StaM U .03.2019 18.03.2019 25.03.2019 01.04.2019
As in sequence
0 1010 6l 10100001 6l # Ql ActNe Const:raint 20 20 20 20

0 1010 6l 10100001 fG06 Ql IActive As in Sequence


Constraint 10 10 10 10

Figure 3.2 Collective Allocations Managed by System and Maintained Manua lly

Product Allocation Object


The product allocation object holds the relevant parameters for product
allocation. Figure 3.3 shows the parameters for product allocation. Parame-
ters have been numbered and described as follows:
0 The product allocation object is the key object for defining all the alloca-
tion parameters and allocation data.
f) It provides the option for transaction object for product allocation -
sales order or stock transport order.
8 It defines the unit in which allocations are maintained.

29
3 Product Allocation

O Possible options for collective allocations include No Collective Alloca-


tion, Collective Allocation Managed Manually, or Collective Allocation
Managed by System.

0 It defines the period for planning; possible values are calendar day, week,
month, quarter, or year.
0 It defines the time zone.
f) It defines the date types for allocation check. Possible values are Materia l
Avai lability Date, Requested Delivery Date, or Goods Issue Date.

0 It defines the Factory Ca lendar for start and end date of the planning
period.

8 < ~ w Product Allocation Object v

PAL 4 PAL 4 Sales O<g Sold to party Material


General Information Characteristics

General Information Date/Time f) Purpose


Allocation Object: o •Period Type: Salos Cl<der.
PAL4 j Week v) 0
Oescripcion: 0 • Period T1me Zooo: Stod< Transport:
[ PAL • Salos Org Sold to party Material UTC D
'
• Quantity Um: 0 *Ched< Oate nme Type:
EA 6l I Requested [)e(Jwry Date vi
*COilective: E) Factory calendar:
COl!eaive Allocation Managed Mai>Jally v J 01 6l )

Figure 3.3 Product Allocat ion Object and Its Infl uencing Parameters

Consumption Direction
Product allocation can be consumed in two ways: by specific period type
(e.g., week 5 or the month of February) or on a cumulative basis (combining
allocations for multiple weeks or months).

Figure 3.4 shows the allocation planned for five weeks and its consumption
for an order of 100 pieces in week 4. Consumption of allocation has been set
for two weeks back and one week forward. Accordingly, the order of 100
pieces consumed allocation as follows: 20 pieces from week 4, then 40 pieces

30
3 Product Allocation

from week 3, then 20 pieces from week 2, and then 20 pieces from week 5.
The sequence of consumption of product allocation is shown in Figure 3.4.
Note that the third period of consumption is week 2, and then it is con-
sumed from week 5- that is, it did not consume from week 1 because back-
ward consumption is set for two periods (weeks) only.

Product Allocation Sequence v

PAL_SO_CUSTOMER_MATERIAL PAL for saleso-g custome< Material

General Information sales Sequence Groups

General Information Consumption Strategy for Sequence

Allocation Sequence: Ba<:kward COnsu1T4'tion:


PALSO_CUSTOMER_MATERIAL 2
Description: Forward Consulr4l00n:
PAL for sates Org Customer Material 1

* consumpllon Unit:
EA

Product Allocation ,, _\

45 ~~~~~~~.....::!t::::================~~·t:::======~·~~
40

_ _e

35
30 ,,8 0'
25
-~
,.. T ....
20
15
10
1 40 I 1 20 I
5
0
Week 1 Week 2 ~ Week 3 Week 4 ~Week 5
Order of 100
PC in wee k 4

Figure 3.4 Consumption of Product Allocation on Current, Previo us, and Future Periods

If no value is stated in backward and forward consumption, then the alloca-


tion will be consumed only for the specified period. In this scenario, an
order of 100 pieces in week 4 \<Vill consume only from week 4 and will be
confirmed only for 20 pieces.

31
3 Product Allocation

Note
Quantities from past and future periods are consumed on ly if those quantities
are lying unused - that is, not consumed previously in other orders.

3.2 Combining Product Allocation and Product


Availability Check
The product allocation check is generally combined with product availability
check in ATP. aATP (as per the 1610, 1709, and 1809 releases of SAP S/4HANA)
carries out product allocation first and then performs the ATP check to
determine the confirmed quantity (i.e., the quantity to be promised to the
customer). Let's now evaluate the order confirmations using product alloca-
tion and product availability check.
Table 3.2 indicates the confirmed quantity for different scenarios after prod-
uct allocation and product availability check checks. In scenarios 1and2, the
allocated quantity (100 in first and 50 in second) is more than the available
quantity (40), and the confirmed quantity is 40 (i.e., the lower of the allo-
cated or available quantity). In scenario 3, the confirmed quantity also is the
lower of the allocated or available quantity (only the allocated quantity has
been confirmed). The same logic is applied in scenario 4. In scenario 5, the
allocated and available quantity are more than the order quantity, and the
confirmed quantity is equal to the order quantity (because the confirmed
quantity can't be more than the quantity requested by the customer).
Therefore, the confirmed quantity is the lowest of the order quantity, allo-
cated quantity, or available quantity.

Quantity Type Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5


Order quantity 100 100 100 100 100
Allocated quantity 100 so 30 120 120

Table 3.2 Confirm Quantity after Product Availability Check and Product Al location Checks
in Different Scenarios

32
3 Prod uct Allocation

Quantity Type Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5


Available quantity 40 40 40 40 150
Conf irm quant ity 40 40 30 40 100

Table 3.2 Confirm Quantity after Product Availability Check and Product Al location Checks
in Different Scenarios (Cont.)

3.3 Basic Configuration for Sales Order

Most of the settings/configurations for product allo cation in aATP are done
in SAP Fiori apps, which we'll discuss in Section 3.5; however, there are som e
prerequisite IMG configurations for product allocation to work with SAP
Fiori apps in aATP, as shown in Figure 3.5:

O Activation of product allocation in aATP


Product allocation for aATP must be activated under IMG path Cross-
Application Components• Advanced Available-to-Promise (aATP) •Product
Allocation (PAL)• Activate Product Allocation.
9 Activation of product allocation in schedule line category
The product allocation checkbox in t h e correspo nding schedule line cat-
egory of the sales order must be flagged in the IMG menu path Sales and
Distribution •Sales• Sales Documents• Schedule Lines• Define Schedule
Line Categories or in t he IMG menu path Cross-Application Components•
Advanced Available-to-Promise (aATP) •Configuration Activities for Specific
Document Types· Sales Orders and Deliveries· Define Availability Check·
Define Avai lability Check Procedure for Each Schedule Line Category.
9 Activation of product allocation at requirement class
Th e product allocation checkbox in the correspon ding requirement class
of the sales order must be flagged in t he IMG menu path Cross-Application
Components• Advanced Available-to-Promise (aATP) •Configuration Activ-
ities for Specific Document Types • Sales Orders and Deliveries •Configure
Requirement Classes or in the IMG menu path Cross-Application Compo-
nents• Advanced Available-to-Promise (aATP) • Product Avai lability Check•
Define Procedure by Requirements Class.

33
3 Product Allocation

Ch1nge View "Actlv1te Product Alloc1tion": Overview

Activate Product Ab:atlon


_,.Acttvat!J
LYes •
.....,

•• ••
Ch1nge View "M1lnt1ln Schedule Line C1t egorles": Oet11/s
, , New Entries Cb !;"~ ti') ~ [} ~ Ch1nge View "Requirements C/1sses": Oet1ils
Schad.Ina cat . ITT! ['-'RP 1 , , New Entries l:D ~ If) ~ [ } {I
"
Emness data Reqmts class 10411 ~·der/delive<v reqmt 1

DelM!rv tb:k D "


Movement type 16011 00 llJ(lds issue:delvy Gl)Item rel.I.div.
ReQti'e<nents Assenillv
Movement Type l ·Step D Av<I. Check Gll Assembly type r.
Order Type 1-1 O P.req.del.<Ched
Req. transfer Gil Order costing 0
Item cateo:>Y D O Ext.c;oa. plamhQ

~9
D Ab:atlon hd. Automatic Ji'lnc;i 0
Acct Assgnt Cat
l..lldate SChed. Lines D NoUldate O Uld. sched IProd.aloc•tion Sl>eclal Stock _[l
lnd.req.reductn u Order Type CJ
MvT lss. Val. SIT
51)ee.!ss. WJ. SIT fr NoMRP D Aval.Con"QOl"Ef'ltS
Type COITQ.check
0
1:
Transaction ftow onne asSE<Tttt D
lnccxr4)1.J"CXed. 30 General 5ched. t.re rCOnfio<.a'atlon capacity check D
Gl)Req./Assembly Con~ation 0 No '4)date 0
PJAvalabAly '
cons.of a:nllg. 0 OCM 0
1~Prod.akxati:ln :

Figure 3.5 Activation of Product Allocation for aATP in IMG Menu Path

Note
If product allocation of aATP is activated, t hen it can't be run in parallel to the
product allocation function of sales and distribution (SD). Th is activation of
product allocation in aATP is at the client level, and it can't be rolled back to use
the product allocation function of SD.

In addition to the listed IMG customizations, the Availabil ity check group for
the availability check also needs to be set for aATP under the IMG menu
path Cross-Application Components· Advanced Ava ilable-t o-Promise (aATP) •
Product Availability Check {PAC) • Defi ne Availabi lity Check Group and also
assigned to the corresponding material, as shown in Figure 3.6.

34
3 Product Allocat ion

~ Disp/.Jy M.Jteri.J/ FG0 7 (Finished Pr oduct)

o Q Aclcltlonal D.;t a .f.i. Org. Levels

Sales: sales org. 2 Foreign trade export Sales text

Material
Oescr.
Plant I1010 Plant l DE

General data
Base unit of Measure fsTl Piece Replacement Part 'l
Gross weight ro,soo Qual. f.FreeGoodsas. ']
Net weli;tlt 0 , 450 Material frelf;tlt orp .=-----,]
Availabitity check Yi lndvid.reqliements
Appr.batch rec. req. 0
Batch management 0

Ch.Jnge View "Av.Jll.Jb///ty Check Control ":

~ New Entries rei ~ ~ ~ ~ a


Av Description TotalSales TotolvReqs Block QtRq No check ... RelChkPlan Advanced ATP
HC No PAC Check 0 RJ •
SP Stock il'Kl Plan. Rec. A A Pl 0 3 •
SR Stock il'Kl Rel. Rec. A A 0 0 3 •
A Active
A 0 3 c t-ive
c c.1ve

Figure 3.6 Activation of Availability Check Group for aATP

Note
Product allocation settings of SAP ERP in the IMG menu pat h Sales and Distribu-
t ion• Basic Functions • Ava ilability Check and Transfer of Requirements• Avail-
ability Check • Availability Check against Prod uct Allocation are not required to
be set up for product allocation to work in aATP in SAP S/4HANA. Those settings
correspond to the product allocation function of SD in SAP ERP.

3.4 Basic Configuration for Stock Transport Order

Product allocation also works for Stock Transport Orders (from the 1709
release of SAP S/4HANA), and the prerequisite IMG configuration is shown

35
3 Product Allocation

in Figure 3.7. Relevant stock transport order types needs to be activated for
product allocation in the IMG menu path Cross-Application Components •
Advanced Available-to-Promise (aATP) •Configuration Activities for Specific
Document Types• Stock Transport Orders• Configure Delivery Type & Avail-
ability Check Procedure by Plant.

Display IMG
~ ~ i3 Existing BC Sets ~BC Sets for Activity ~Aet1vated BC Sets for Act1¥TtY ITJR

Structure
Advanced AvaHable-to·Promse (aATP)
Conllguratlon Aetlvitles ftr Specific Documentj)pes
• Sales Orders and Deliveries
• Planned and Proructlon Orders
• Reservations
Activate Product Allocation Check in Advanced ATP
• Stock Movements

• !&a @ Conftgll'e Deivery Type & Availabity Check Procedure by Plant


Conftgll'e Deivery Type & Availablity Check Procedure by Storage Loca · n

Change View "Stock Transfer Data": Overview


~ New Entries LD §, ~ ~ ~

Cl). Oser.
OT SPt Name 1
UB2 Enh. Rets STO ..000 1 Werk 0001

Figure 3.7 Prerequisite IMG Configuration for Product Allocation to Work for Stock Trans·
port Order

Note
Availability check settings are also needed for product allocation to work in
aATP. In case of business scenarios in wh ich only product allocation is needed
with no availability check, then the Availability Check control will be set as KP
(i.e., no check}.

3.5 SAP Fiori Applications


Product allocation in aATP is managed by five SAP Fiori applications as of
the SAP S/4HANA 1809 release, as shown in Figure 3.8.

36
3 Product Allocat ion

Product Allocation Inventory Management Overview Manage Reservations Inventory Analytics

Configure Product Manage Product Manage Product Assign Product to Produc-t Allocation
Allocation Allocation Planning Allocation Product Allocation Overview
Data Sequences

C'+ ~ ~ m
.,,
- ...=··
Figure 3.8 SAP Fiori Apps for Product Allocation in aATPas of the 1809 Release

Not e
There are certain prerequisite settings (generally executed by Basis or SAP Fiori
consultants) for SAP Fiori apps to appea r in a user's SAP Fiori launchpad. Re-
quirements for the backend and frontend software components, as per the SAP
Fiori library, first need to be verified and implemented. Configuration sett ings
for SAP Fiori apps for product allocation then need t o be set up as described in
Table 3.3.

SAP Fiori App Activation of Activation of Assignment of


ICF Nodes : OData Services: User Role:
Transaction SICF Transaction Transactions
/N/IWFND/ PFCG, SU02
MAINT SERVICE
Configure product /sap/be/ ATP- CONFIGURE- SAP- BR-
allocation uiS_uiS /sap/ PRODAL LOC INTERNAL
confprodallocsl SALES REP
-
Manage product /sap/be/ ATP MANPROD- SAP BR
- - -
allocation plan- uiS uiS/sap/ ALLOCPLNGDATA INTERNAL
ning data manpalplngdatsl SALES- REP
Assign product to /sap/be/ ATP ASSGPRODTO- SAP BR-
- -
product allocation ui5_ui5/sap/ PRODALLOC INTERNAL
assgprodallocsl SALES- REP
Manage product /sap/be/ ATP MANPROD- SAP BR
- - -
allocation ui5_ui5/sap/ ALLOCSEQUENCE INTERNAL
sequences manpalsqncsl SALES- REP

Table 3.3 Prerequisite Settings for Product Allocation SAP Fiori Apps to Appear in
SAP Fiori Launchpad

37
3 Product Allocation

SAP Fiori App Activation of Activation of Assignment of


ICF Nodes: OData Services: User Role:
Transaction SICF Transaction Transactions
/N/IWFND/ PFCG, SU02
MAINT SERVICE
Product al location /sap/bc/uiS_ui S/ ATP PRODALLOC- SAP BR
overview sap/prodal locovpsl OVERVIEW INTERNAL
SALES REP

Table 3.3 Prerequisite Settings fo r Product Allocation SAP Fiori Apps to Appear in
SAP Fiori Launchpad (Cont.)

In the following sections, we will discuss each of these SAP Fiori apps in turn.

Configure Product Allocation


The Configure Production Allocation app, shown in Figure 3.9, allows you to
create, change, delete, and search for a product allocation object using its
characteristics, date range, and general information.

Product Allocation Object v

PAL 4 PAL 4 Sates Org Sold to patty Material

General Information Date/Time Purpose

Allocation Object: Period Type: Sales Order.


PAL4 W... (02) v..
~pcion: Period nmc Zono: Stock Transport
PAL 4 Sates Org Sold to party Materiat UTC>O(UTC) No

Ouandty Unit Check Date Time Type:


ea'h (EA) ReqUfl.ted Oe'Mtry Date (01)

Collective: Factory Calendar:


Collt(tiile All.oal«k>n Managed Manually (02) Germany (Stan~rd) (01)

General Information Characterisde:s

Characteristics (3) Y•dd 0.1 ... I


Ordlnat N1JY1ber Cl\ar.ct et'btlc

0 1 Sales OrganlzaUon

0 2
f) Sold·To P~ity ·Customer N\lmbtr

0 3 Material Number

Figure 3.9 General Information and Characteristics for Product Allocation

38
3 Product Allocation

The Select Characteristics pop-up appears when you click Add 0 ; in it, rele-
vant characteristics can be selected and saved.

Figure 3.9 shows the produ ct allocation ob ject PAL 4 with characteristics
value combination (CVC) as Sales Orga nizatio n, Sold-To Party, and Materia l
Num ber 8 .

Manage Product Allocation Planning Data


The Manage Product Allocation Plan ning Data app, shown in Figure 3.10,
allows you to do the following:

• Maintain planned allocation data with defined characteristics and time


period.
• Define activation and con straint status.
• Display (in bar chart) planned, available, and consumed quantity.
• Download and upload the characteristic value combination in CSV and
Excel files.

PAL 4 PM. .. sates Ofg Sokt II) party IAaterial

0
Selecdon Rarge:
zs.oi.2019. 1s.os.2019 m8
Product All ocation Planning Data (2) o. ~ c~tus ~c!an sutus Copy SllGW~lion o.ttc• ~f)1
C<ln$tralnl SlllUS 25.02..2019 04.03.2019 11.03.2019 18..03.2019 25.0l.2019 01.04.2019 06
A$k'I~
0 1010 OJ 10100001 61 6
Constt..,. 20 20 20 20 0 0

ID 1010 61 10100001 61 FG08


R~lettd
A\'abblity
I 10 10 10 10
I 0 0
0 0
Figure 3.10 Manage Product Allocation Planning Data App

In Figure 3.10, you can see the following elements:

0 Name of product allocation object.


8 Date range for the validity of product allocations.
f) Add additional lines for planning for CVC.
O Share of product allocation object (by email).
9 Collective allocation maintained manually.

39
3 Product Allocation

0 CVC values as defined in the Configure Product Allocation app.


O Status that can be changed to Active or Inactive for each CVC line.
O Planned product allocation data for each characteristics and time period.
0 eve with time period that can be down loaded and subsequently up-
loaded after editing in downloaded fi le (in CSV or Excel}. This is very
useful for the mass creation and update of CVCs. Updates on the same
downloaded file also ensures correct formatting.
41!> Change of constraint status can be changed with the following four pos-
sible options:
- Restricted Availability
If Restricted Availability is chosen, the quantity is restricted to the
available quantity in the applicable time periods and results in a full,
partial, or no confirmation at all. The system will record the consumed
quantities.
- Unrestricted Availability
If Unrestricted Avai lability is chosen, the available quantity of the
period or the consumption range isn't taken into consideration and
may lead to an overload situation. The system will record the order
quantities.
- No Availabi lity
In this instance, product allocation checks result in zero confirmation.
- Not Relevant
The product allocation available quantity will not impact the overall
ATP check, meaning that the product allocation check is deactivated
for the eves.
- As in Sequence Constraint
Constraint as maintained in the Manage Allocation Sequences app (as
described in the Manage Product Allocation Sequences section) will be
considered.
G Access a display of consumption of planned, available, negative avail-
able, and consumed allocation in a pictorial chart, as shown in Figure 3.11,
by clicking Show Consumption.

40
3 Product Allocation

v OISplayOotumeM Flow nem OUlp.CVlew f\1ore v

I< < > >I


Sales Document tem 10 ttern category TAH Stanaara 1em
Material FG08 FINl26, MTS-DI, PD, senainummet

8 < ~ w Sales A B1lngDocument Conditions Acc~tAss1grment $(hecllle lines


Sal•sB Sh1pp1ng
PAL 4 PAL 4 Salff Ofg Sold to patty M•tWl

Pt-riod T~ ; Wfflc (02) Fe>:eel Date ar.o Oty Otoet Ou~nbty < PC
Perlod Timi Zone: UTC+o (UTC) oeway Time v OelNered qty 0
Ou&ntJty Unit Nd\ (EA) l

·-·- ·-·=
~ : ~~don M"'""'lod M•rwU)' (02) l
I e_ I •I 0, Sales 0, Stlipp1ng 0. Procuremern
OuannnerJDates
Selection R•nP'. P. OefNtty Date Or\'.ler Ouantity Ccmrmea Oty ... Oelrvety810tk
rn
25.02.2019 . 24.os.2019 0'"11.0 .03.2019 1£9 • • 4 PC v

Product Allocation Planning Data (4) SU/ch Q. Switch to O."rlp~r..,,., ShOw ConsutnptiOn J.
.----.
O S.s Org•nizatiOtl Sold·To Pc.tty· Cu$t... I Status Constraint Sc&1uS 2'S.02 2019 Ool.03.2019 U.03.2019 8.0J.2019 25.03,2019 01.04.2019
Restl'kted
!!.) 10 10 10 100001 Actt1e Av•!i..bUty 10 10 10 10 0 0

,.

i
.I u

. •~
~

j
.!
'•i
' g

I
,.....,.., •0

Figure 3.11 Display of Consumption of Prod uct Allocation


·--
Manage Product Allocation Sequences
The SAP S/4HANA 1709 release introduced the Manage Product Allocation
Sequences app, as shown in Figure 3.12. This app combines multilevel sup-
ply constraints (with alternate sources of supply) to determine confirmed
quantities for sales orders and stock transport orders.
The concept of multilevel product allocation with multiple product alloca-
tion objects is illustrated in Figure 3.12. Material/plant combination has

41
3 Product Allocation

product allocation objects at two levels (first at the sales organization level
and second at the customer level). A customer orders 40 pieces of material
FG09; the available stock quantity is 100 pieces. The system first consumes
20 pieces from the first allocation object with sales organization, then 10
pieces from the second allocation object with a specific customer from a
product allocation perspective. Finally, the order is confirmed for a quantity
of 30 pieces (20 pieces + 10 pieces), as per the product allocation, for an
order of 40 pieces with an available stock of 100 pieces.

Sales order
Sales org: 1010 - ... A • • • • •
Material: FG09
Plant: 1010
Product allocation object 1
Order qty: 40 PC
Sales org - Materi al/ plant: 20 PC
,...... Confirm quantity:
30 PC

Product allocation object 2


Avail able quantity: 100 Cust omer- M aterial/plant: 10 PC

Figure 3.12 Concept of Product Allocation Sequences

Not e
The functi onality of the Manage Product Allocation Sequences app is similar to
SAP APO's "logica l OR" funct ionality with the product allocation procedure.
GATP in SAP APO requires complex configuration and also updates in the prod-
uct master to the product allocation procedure field. However, settings in aATP
are very simple and flexible (as explained further in this section) and do not
require any update in the product master w ith product allocation procedure, as
in case of GATP.

The process of establishing the settings required for the scenario as shown
in Figure 3.13 is as follows:
1. Two product allocation objects (PALl and PAL2) are created with the Con-
figure Product Allocation app, with the sales organization/material/plant

42
3 Product Allocation

characteristic value combination for PAL1 and the customer/material/


plant characteristic value combination for PAL2.
2. Product allocation objects (PAL1 and PAL2) are then planned in the Man-
age Product Allocation Planning Data app, as displayed in Figure 3.13.
Product allocation objects PAL1 and PAL2 have been planned for 20 PC (O ;
first sequence of allocation) and 10 PC per week (8 ; second sequence of
allocation}, respectively, for 3 weeks, starting February 25, 2019.

Product Allocation Object v

PALl Prod AUoc Obj S.les Org Mell

Set.ction R_,,,,•:
28.02.2019. is.os.2019 rn
Product Alloca1ion Planning Data (1) :-.. Add Ol.loge Sta:us Oi.ange Con~ralnt Stotus Copy Show Consumption Delete .!. ,!.
O Sates ().<ganit11ti0n M.atfflal Nvmb« Sc.ttus ConstralM StaM 2S.02 2019 04.03.2019 11.03.2019 18.03.2019 25.03.2019 01.()1.2019 0$.04..2019 15.04,2(

0 1010 FG09 0 0 0

Product AUocabOn Object v a.


-
5.i.etion R6f'ICe:
2s.02.2019 -1s.os.2019 rn
Product Allocation Planning Data (1)
O
0
Sold·To P<wty · Cust...

10100001
Matel1M Numbef

FG09
l
~M~
Act;..;:
s...m
Conw*1t s.t.ws
As In St<ivtneit
Consa-aint
-..:;;:::.......;
Add

2$.02 2019

10
Change Status

04.03.2019

10
Chqe Constraint Status

ll.03.2019

10
18.03.2019

10
Copy Show Consuqitlon

2S.03.201t.I

0
Ol.<M.2019

0
O.tece

08..<M-2019

0
.!. .1.
1$.04.2<

Figure 3.13 Product Allocation Planning Data Maintained in Manage Product Allocation
Planning Dat a App

3. Product allocation sequence PALSOCUST is then created with two con-


straints - first with product allocation object PAL1 as the first sequence
and second with product allocation object PAL2 as the second sequence
in the Manage Product Allocation Sequence app, as shown in Figure 3.14.
A date range is also specified for the product allocation sequence.
4. Product allocation sequence PALSOCUST is then assigned to the material
FG09 and plant 1010 combination, as shown in Figure 3.15.

43
3 Product Allocat ion

8 < ~ ~ Product Allocation Sequence v c.


PALSOCUST ~ s.qu.nce Soalos Otg ~- ml re
~.1 tnfOJINdon
I~ Stqvtnot °''~ I
GenerM lntorma11on Consumption Slr<)tet'/ for Sequtnee

•PALSOCUST
" ' )11'1 <;r
- "'
0
rd c-. Ttpt °"'

"' """'
PAL S.C.utflef Salfl Org Cu!.t«MJ

Co •
eacl'l(EA)
_.,. 0
Pini
No
~
"""""'-
Allorr.wd

.._

- ,. --
Sales Sequence Groups (2) 0. <!>
Seq.......ceGrwp 8&el.w.Md Conwmpllorl Fcwward Gonwrnpciorl

l •• PAl 5.-s Oft \la<eri.M 0



' PAl Cusc- MM.W 0

...,,,,
--
Constraints (1) 0. <!>

..
Oult!tity UM

V*«Y $1¥t 10 112017. Ol'CM);O(I


PAl ~ °'8 Mall
-.""'
PAU
"""" Allooc.tltlon A:11i.

1.000000
8irdtwl.M ComU!l'lpdon Ctlfodt [).)c1> l11N> Tyiw

• A:tqUf'Stt<I Otl"-Y Oar•


C~rani

A:Hll'kttdAV~
Sul"-" VAlld1iy End

01"01.2100, 00:'9:S9

Constraints (1) ........ 0. el


nm. Typt
Ou.nt.ty Unc

EA """""""
PAI. °'51omff (IW(ft.illl
'""'""
PAL2
"""" Alloctclon RMI•

1.000000
B•c~C~lon

0
OM<k 0.1•

~'-""od O.UVtty CiXt


Conw.nStttut

A:Kllk* Av11ll11btlll)'
V.lidl!yEnd

01-012100. C»:S9;59

-V•lid"Y Sr.-i:. 10 112017, 01--<IOOO

Figure 3.14 Settings in the Manage Product Allocation Sequences App

.
8 < ~ ~ Assign Product to Product Allocation v c.
Standard v re

,_,,,. 0.
E6tio&SUM:
All v
~$4q--.c:•

6'
~fll*l'I:

6'
laM Cti.rc-<! f)y:
c5'
....""""' °"' 6'
CrN:9dlly ~01111: M.w.t111I:

6' 6' 6'


'''"" 6' Adapt ftlttn (1)
m
A fl

Product Allocation SeqUf'nces (S) <!>


IJloeMion s.q~·
._._ i..uc~ey O'••i.d By f.,ac)1 ~o E>ato r....,.
<............ ""'
A8GPLUSll'At. AJ!o~M WMCI ~lioft,,.,;ch PAI. :Z.022019.1620:35 N<h(EA)

PAL WITH ALLOCA~ RATii PAl kif M.Koll.tl ~ Alloc.ttion R.tlo 2:8.02..2019, t8.1S:4) Neh(~

PALSOCUST PAl Sequtnee S.lin °'J~ 28.02.2019, 16;41:33 ffCh (EA)

8 < !II ~ PrOducc Allocation St'quence v 0.

PALSO CU ST PM. ~ s.c.. Ors Cl.OM°'""" ml [<:

~Unit; ...:h(EA) Crt-ouon O.e lmt• 10.11.2017, 16..'0ot 2S


Cloot.O By:
tMt Chwl$e ~ ~ 28.02 2019, l&A.133
l.MIC~od8y:

Material·Plant Assignments (1)


- 0. .±. <!> ..
.,
, ...
M•twllll

flrill6,MTS·Ol,PO.Ni:> Seri#. IOI' P6


"""'
1010
PbrclOEW~
V.:.Udlty End

311l.l099. 18 ~-"
VlAdl.yS~

09112017. 190000

Figure 3.15 Assignment of Material and Plant Combination to Product Allocation Sequence

44
3 Product Allocation

5. A sales order is subsequently created for the specific customer for mate-
rial FG09 at plant 1010 with an order quantity of 40 pieces. Product allo-
cation has been consumed at two levels, first from PAL1for 20 pieces and
then from PAL2 for 10 pieces, as depicted in Figure 3.16 (0 and f}, respec-
tively). It shows the confirmation quantity as 30 pieces (20 pieces + 10
pieces), as set in two allocation objects (with available quantity as 100
pieces).

St.rnd.rrd Ord~r: Av.rll.rblllty Control


Deivery proposal Continue ATP <JJOntities scope of check Other plants Product '*>cation
r--~

Item 110 I Sc1ied.1ne


Material FG-09
FIN126, MTS-OJ, PO, 5eriah.mrner
Requirement Se1J0011t
Plant fiOiOj Plant I CE Wallclorf
Req.deiv.date l2s .02 . 2019J _Open
.,I -- Qua
- nttty
,..·- - - . - - - - - -4-o'_p_c_i,.I
OF1 Qty/Date MaX.Part.Deive1ies lo

O'"le·tlne def. on req. def. dte : not pos-


Dely/Conf.oate 28.02.2019 / 28.02.2019 Confi'mecl Quantity [
Defy proposal
1oi. 03 . 20191I 28.02.2019
Dely/Conf.oate COlfJRl.£1) QTY L
-
@Product Al'ocat:O"l: Conftrmaton Calcclat1on x

~ Alloc ation Obj e ct Pt: i ocity Alloc Ra t l!! Chl!!c k Dat.e Timi! T'ypl!! Backward Consuaption Fo cvai::d Consunption Pl!!ciod Typl!!
Charact.eci stic Value Coabination
Mat.Avail . Date Check Dat.e Requicenent qty Confirnetion Date Confiraation Oty Alloc. UoM

GI PALl l 1 ,000 LFDAT 0


PALl , 1010 , FG09
28 . 02 . 2019 01.03.2019 40 01.03.2019 20 EA

t::l PALZ 2 1 , 000 L fDAT 0


PAL2 , 0010100001, rG09
28 . 02 . 2019 0 1 . 03 . 2019 20 01. 03 . 2019 10 EA

Figure 3.16 Consumption of Product Allocations in Sales Order at Multiple Sequences

Note
There are business scenarios in which sales are handled in each (EA) unit and allo-
cations are planned in a different unit. aATP converts the sales unit to planned
allocation unit through the Allocation Rate, as shown in Figure 3.17. A typical
f ertilizer manufacturer sells ferti lizer in bags containing 20 kg of fertilizer O .

45
3 Product Allocat ion

Figure 3.17 shows that sales unit (EA; 8 ) has been converted to planned alloca-
tion unit (kg; 9 ) via the allocation rate (20). Consumption of allocation is also
shown as 100 kg (20 kg x 5), converting the confirmed quantity of five bags for
the sales order to 100 kg of planned allocation quantity O .

PAL Wl1ll M.10CAJ10N RATE I

10

Constraints (1)
_,,
0.
.. ®

)112 209?. 23.5'.5'


V.uiMy$t.i; 2$01.201,.C».OOtOO
Stqt.-- c-io...-..: l

Orcer Ouncy ...


s fA

Ptoduct Allocation Object v

Ptriod TJ119 WNlt (02)


p..ioci n.w z-· c-~
lo.-yu,., IG!Qgr""'(t:G)
wq £T) OMloNIBy
C.~ DM• lilM' 2'102.2019., 2L"26.U
a.-ch.lo~&,-

--
~ No CoucWt Nllx.llflofl 101) LMI Clw.~ 0.. Tlr'N: 09.C420l9, 1~0119

~.05 201, . i" 01..2019 m


Product Alloc3.~ Ptamircg Q;!ta (1)
~ SaltsOrs....cac1on SoklT~P~·C'*·· M•.ilalMl.lmtM<

1010 10100001 ,..,., 200.000 200.000 200.000 0.000 0.000 0.000

CoMumptlon

"' .

"'
.~

0
~
·~ -
l
• ..
• •
l10S.2019 OlOf.2019 11-0l101t 11<$_.~lt ,.Of.,2019 0101.2019
........
Figure 3.17 Allocation Rate for Conversion from Sa les Unit to Product Allocation Unit

46
3 Product Allocation

Assign Product to Product Allocation


Assignment of material and plant in the Assign Product to Product Alloca-
tion app is a prerequisite for product allocation check. The system finds the
product allocation object for product allocation check through this assign-
ment.
The Assign Product to Product Allocation app, as displayed in Figure 3.15,
allows you to assign a material and plant combination with a specific validity
range for a product allocation check. (It's a prerequisite for a product alloca-
tion check.)

Note
In the product allocation functionality of SAP ERP or SAP APO, the product allo-
cation procedu re should be assigned in the materia l or product master. In aATP,
the assignment of material and plant to a product allocat ion object is done
through an SAP Fiori app. The product allocation check can be switched Off or
On through the app without requiring any change in material or product mas-
ter. Also, this assignment has a validity range that will be very useful fo r sea-
sonal or promotiona l products.
Info structures and other product allocation-related data {allocation procedure,
steps, etc.) are not required to be defined for product allocation in aATP in SAP
S/4HANA.

The assignment of material and plant must be unique for a specific product
allocation sequence. An error message appears if you attempt to assign the
same material and plant combination to multiple product allocation
sequences. Consider an example: Material FG08 is assigned to product allo-
cation sequence SALES SEQl. If the same material FG08 is assigned to
another product allocation sequence PALSOCUST, then an error message as
displayed in Figure 3.18 appears.

47
3 Product Allocation

8 < ~ & Product Allocation Sequence v a.


PALSOCUST PAL Sequence Sales OrgCustomer

Material-Plant Assignments (2) Search Q. Add Delete J. t © r•


-~

D Material Plant Validity End Valldrty Start

D FG09 o'l 1010 o'l Ol.Ol.2100, 00:59:59 (0 lO.ll.2017, 01:00:00 (0

lo FG08 61 1010 61 01.01.2100. 00,59,59 re 2s.02.2019. 22:04:34 re

< Messages

<D Material-plant FGOS / 1010 was already assigned


from 28.02.2019 to 31.12.2099 to sequence SALES
SEO l.

Figure 3.18 Error for Mu lt iple Assignment of Plant and Material Combination to Product
Allocation Sequence

Product Allocation Overview


As of SAP S/4HANA 1809, there is now a new SAP Fiori app: Product Alloca-
tion Overview, as shown in Figure 3.19. It allows you to do the following:

• Analyze the produ ct allocation situation (e.g., low consumption, h igh


consumption, overload consumption).
• Drill down to the relevant sales orders and stock transport orders.
• Open the following three apps:
- Monitor Product Allocation Periods
You can see three cards in Figure 3.19 for Overloaded Periods, Under-
loaded Periods, and High loaded Periods. If you click one of the cards,
then you get the Monitor Allocation Periods app, showing product
allocation object, eve, and product allocation situations (planned, con-
sumed, and available quantity) for the corresponding period and also

48
3 Pro duct Allocation

the corresponding sales orders or stock transport orders. If the card 0 .


as shown in Figure 3.19, is clicked, then it shows the planned, consumed,
and available quantity for product allocation object PAL4 for CVC Sales
Organization, Sold-to Party-Customer Number, Material Number and also
the corresponding sales order, as displayed in Figure 3.20. Load percent-
age is calculated (load= consumed quantity/ available quantity; 20/10 =
200%) and displayed based on the consumed and available quantity.

8 < ~ w Product Allocation Overvie\'1 v a.


Standard v
Not filtKed
v

overloaded Periods
By Load
Underloaded Periods

"'lood
Sol 302
.,,...
Hig11loaded Periods

Load~ 8096 and 10096 v


lood

04.03 2019 1L03.2019 0 200 ..


,...
2'$.02.2019 04..03.2019 o.. 15.04.2019 23.04.2019 100 ..
29.04 2019 06.05.2019 120"

ll..03.2019 18.03.2019 o.. 23.04.2019 29.042019 100 "


Characteristic Value Combinations

.
'"u
By Load o..

., .....,... .,......,,_
18.03.2019 25.03.2019
Product Allocation Order Items '"' 22
1010:001010000l:FG216 PAL4
o..
.... ~.03.2019 OL04.2019

All v

Ol.04 2019 08.04 2019 0 ..

-
1010; 0010100001; PAL4 Orde1 flom 0.-derType -SU.us
.... Product Allocation Order ttems
10000496 . 10 Parts.11y conr•...
1010: 0010100001; FG08 8 PAL4
22
Sales O!'CMJ

-
1010:001010000l:FG12
....
PAL4
Product Alloaition OrcMf lttms by A~T...
1()()()(M95 • 20

10000604 . 10
..,., °""'
Sales Order
-lfyC°""···

FollyC-...

• ... 10000599 . 10 Sales Ordtr fulty Co11.· •1111id•••


0010100001; FG215 ABCPLUSPAL

I ... 10000600 . 10 SalesOrdH Partialty Contir...

Figure 3.19 Product Allocation Overview App

49
3 Product Allocation

overtoaded Periods
By Load

Pe-riod Start Date Pe-nod End Date load

04032019 11.032019 200% >-----~

I Allocation Period v 0.

04.03.2019
PeriOd StM Date: 04.03.2019 Ch&ractff<Slie Vatue Combinauon: 1010; 0010100001; FG12

Period Encl Date 11 03.2019 Ch31act~ Vatve OeKriptlon Dom. Sttles Ort DE; 1.nl<tndslcunde DE 1; FIN126.MTS·Ot,PO.No Serial TM POSC
Allocatiot\ Object: PAL 4 (PAL .. S;ilo$ Ora S<*l 10 p.)rty ~Ao:tcNI} Ch&rectffdties: Sales OrganizabOt\; Sold-To Party· Customer Nu~; Material Number

Gtnttal l.ntormaliOn Ordtf Items

Planned Ou.ant•ty: - Load:


10,000 EA • 200,000 96

COf\Wl'l'led Oua11ti(y Constra«'t 5(atus:


20,000 EA Rfftrict9d Avallabity

Av.lil.:ablo Ouanlity Act;,,illllOO St.iitu


·10.000 EA AcWe

Order Items

Order Items (1) 0. ®


Order Item Order T)'Pe Material Consumed Ouandty In Allocation Unit Sequenc-e Com.ttalnt Status Avail.abll"-to.Promlse Status

.__,1,,,
0000600
=~·l"'-
0 _,,.
Sa~
le'-'s0.""d.,,e<' - '
F""Gl._,2..,,!F,,,,,1N.,,l2,,.,6.M,,_,T-"S-"'10-"',PO"",t;"'-o-"Se= ' T,,,,M'-"PO"'SC""-l_ _ _ _ __.2"'0,000=.><EA,__,,•~es,,,,uk,,,1ed,._A,...•=•lla~'"=1ty
'""- ,__ _.=
Pilttiatt~ti!lI•>O!!.oU/.G<..,m~_I

Figure 3.20 SAP Fiori App for Monitor Product Allocation Periods

Monitor Product Allocation Characteristic Value Combinations


You can see the card Characteristics Value Combinations in Figure 3.19.
If you click 0 in Figure 3.19, then you get the SAP Fiori app Monitor
Product Allocation Characteristic Value Combination, showing the
details of eve with all quantity key figures for the respective periods
of CVC, as shown in Figure 3.21. Load percentage is displayed as 40%
based on the calculation load = consumed quantity/ planned quan-
tity; 4/40 = 10%.

50
3 Product Allocation

Characteristic Value Combinations so• u


By Lo.ad

- - - - -= -- - - - - - - - -Characteristic
- - - -Value - -Combination
- - - -v - - < 1010:0010100001; FG216 PAl4
8 < till !i!E"
39'6
1010; 0010100001; FG08 Dom S.les 0'11 DE; lnl•ndskunde OE 1; FIN126.MTS-01,PO,No S.ri•l
1010; 0010100001; FG201 PAl.5

-
Alloc.a~ion Ob)Kt PAL 4 (PAL 4 Salos OJc Sold to P¥t>' M11t9fial) Chateaeri:stic:s: Sales Ofganiution; Sold·To Pa
Period TY'P'· Week Cons!Jalnt StaM: Restricted Av;allabt«y
I Aggregated Planned Ouant11y. 40,000 I Activation Suorus: Adve
1010;00101000Cl; FG08 PAL4

Allocation Periods
- 1010;00101000Cl;FG12
....
PAl4
Period R••·
2s.02.2019 . 19.o:i.2019 rn • ...
Allocation Periods (4) S..«h ©
PfflO<f End O.ate Planned Ou~ Consumed Ou¥rtity .-•bble Quantity

25.022019 04,03 2019 10.000 EA 0.000 EA 10,000 EA

04.0 32019 11.032019 10,000 EA 4,000 EA 6,000 EA

11.032019 18.03 2019 10,000 EA 0,000 EA 10.000 EA

18.032019 25.03 2019 10.000 EA 0.000 EA 10,000 EA

Figure 3.21 Monitor Product Allocation Characteristics Value Combination App

Monitor Product Allocation Order Items


You can seethe Product Allocation Order items in a pie chart in Figure 3.19.
If you click the area marked as 9 , then the corresponding order items
(sales orders or stock transport orders) appear sorted by the earliest
requested delivery date, as shown in Figure 3.22. This app also provides
the option to navigate to the respective order items and to the Configure
Product Allocation and Manage Product Allocation Planning Data apps.

Note
SAP Note 2691783 provides t ro ubleshooting and addit ional information fo r prod-
uct allocat ion with aATP.

51
4 Alternative-Based Confirmation

Monitor Product Allocation Order Items v Product Allocation Order Items

Standard• v 22
Filttrtd By (1): Av.ailablt-to·Promis. Status
v
Order Items (6)
Produ« Allocation Order Items by AYailable-T...
Requt's.t
0rdH Item Plant
""""' Ouanf

100004!16. FG09 (fl\1126,MTS.Ol,PO.No Striiaol for 1010 (pt..-.c; 1 OE


16,012019 5,000 PC
10 PB) \'t•ldorf)

10000600. Slits FG12 { fl'lf126,MTS·Dl,PO,No Stnal TM 1010 (ptfint 1 DE


10.03,2019 34,000 PC
10 OrdH POSC) \'/alldorf)

Av31.1ble to Promise S~tus.: Pa.ltl<\lly Conflrme<t Of Unconr.nwd

100006.34 • s-.s 1010 (ptan1 l OE


18.03.2019 5,000 EA
lO OrdH FG201 (Sf No $trial no ~teh) \'/atldorf)

• IVltf ~ l.4af
. P.-..lly~OfU~
10000&76. SMM
FG.215 (Sf Ne> sfrial l'IO bateh A.ATP ABC) lOU (Plant 2 OE: JCl.03.2019 35,000 EA • tuty~en-n.ne
10 OtdH M"°"")

AvaJ.abt.-t<>-Ptomtse S~tus.: P.lrtially Con!irmed Of Uncon,.med

10000722. S.ttt FG216 (SF No serial r.o batch AATP PAL 1010 (P!MC 1 OE
22.04.2019 90,000 EA 20,000 EA 0,000 EA
10 OrdH ABC) Vtalldorf)

AV<)Ai!bl• to-Prcm<M St.ill'$ P1ortitlly Confirmed°' Unconf'irmtd

10000495. Sale-s FG09 {FINl.26,..US.Ot.PO.No $tflll fOf 1010 (Piton! 1 OE


20
16.01.201, 10,000 PC 0,000 PC 10.000 PC
Ordttt PB) V.'.-lldorf)

Figure 3.22 Monitor Product Allocation Order Items App

4 Alternative-Based Confirmation
Alternative-based confirmation (ABC) is a functionality similar to rule-
based ATP (RBA) of GATP in SAP APO. RBA is used to substitute the location
(plant) or material (product) based on predefined business rules such as the
following:

• If a material isn't available in the Munich plant (for example), then the
availability check can be automatically switched to the Frankfurt plant,
then the Dusseldorf plant, and so on.
• If a specific material isn't available, it can be substituted by a material
with an equivalent or higher specification. For example, if a customer has
requested a smartphone in a black color with 16 GB of storage and it isn't
available, you can substitute a smartphone of the same make and model
in a gray color or the same phone in black but with 32 GB of storage.

52
4 A lternative-Based Confirmation

N ote

Many SAP APO GATP customers use RBA to substitute a plant or material, and
are looking for the similar functionality in advanced ATP.

In this section, we'll take a closer look at ABC: key SAP Fiori apps, how it
combines with product allocation, and expected enhancements.

4.1 What Is Alternative-Based Confirmation?

SAP released the initial version of ABC in the 1809 release of SAP S/4HANA,
and ABC is expected to evolve in future releases. The ABC functionality as of
SAP S/4HANA 1809 is captured in Figure 4.1.

Building ru le
Plant: 1020 Plant: 1030
MAX- ON - TIME- CONFIRMATION M aterial:
ATP quantity: 60 ATP quantity: 40
FG215

Plant: 1010 Plant: 1011


ATP quantity: Nil ATP quantity: 10

Sales order creation Sales order creation


Material : FG215 Materia I: FG215
x Plant: 1010 Plant: 1020
Requested quantity: 55 Confirmed quantity: 55

No confirmation of sales order Sales order is confirmed and delivering


plant is changed to 1020

Figure 4.1 ABC Functionality as of SAP S/4HANA 1809

53
4 Alternative-Based Confirmation

Note
GATP in SAP APO considers the plant to be based on the predefined master data
substitution rule (in which the original plant is A, then the system checks plant
B, then plant C, etc.); however, ABC considers all the relevant plants for that par-
t icular material-pla nt combination and selects t he alternative plant based on a
specific key performance indicator (KPI).

In Figure 4.1, a sales order is being created for material FG215 in plant 1010
with requested quantity of 55 PC. The sales order does not get confirmed, as
there is no stock of this material FG215 in plant 1010. Availability for this
material is then checked in other plants, and the plant 1020 is selected, as
this plant can confirm the full requested quantity. The delivering plant of
the sales order is then changed from 1010to1020, and the sales order is con-
firmed for the full requested quantity. Plant 1020 has been selected consid-
ering the building rule MAX_ON_TIME_CONFIRMATION(i.e., the system selects an
alternative plant that can confirm maximum quantity on the requested
delivery date). Plant 1020 has been selected, as it has an available quantity
of 60 PC and can confirm the full order quantity. Plant 1011 has not been
selected as an alternative plant, as the available stock quantity is only 10 PC,
whereas the requested order quantity is 55 PC.

4.2 SAP Fiori Applications


There are two SAP Fiori apps for ABC in the 1809 release of SAP S/4HANA.
Let's walk through each:

• Configure Substitution Strategy


With this app, substitution strategy is defined with a substitution item
type, as displayed in Figure 4.2. The substitution method and building
rule are defined in the Strategy subscreen.

54
4 Alternative-Based Confi rmation

ATP Alternative-Based Confirmation

Configure Configure
Alternative Control Substitution
Strategy

z
8 < ~ & ' Configure Substitution Strategy v

Standard v
FU1ered By (1): Editing S1at"5
v

Strategies (1) I' I + @


D Strategy Name Strategy Oesetlption Substitution lwm Type Creautd By Created On Chang4Ki By Ch.anged On

0 ABC_Ol Alt Based cooflrmoUon 01 Force lnUnc Sub!;titudon MROY 2210.2018, 17:00:36 MROY 22.10.2018, 17:01:22 >

Strategy v

ABC_ Ol Alt BasedconfirmationOl E!lll Delete Copy ~

Strategy Name: ABC_Ol c...ated By: MROY

Strategy OesctipbOn: Alt Based confirmation 0 1 Created On: 22.10.2018, 17:00:36

Substitution Item Type: Force lnline SubstihJlion Changed By: MROY


Changed On: 22.10.2018, 17:01:22
Substitution Methods Building Rule

Substitution Method

Plant Substitution >

Building Rule

Alternative Determination

MAX_ON_TIME_CONFIRMATION (Maximum Conflrmadon EarUer)

Figure 4.2 Configure Substitution Strategy App

• Configure Alternative Control


Control characteristics for ABC are first selected fro m Add Characteristics,
as displayed in Figure 4.3, and t h en assigned to a Substitution Strategy
with this SAP Fiori app. Subsequently, ABC is activated.
For example, both customer and material have been selected as character-
istics for ABC and assigned to Substitution Strategy ABC_ Ol, as in Figure 4.3.

SS
4 Alternative-Based Confirmation

Customer 10100001 and material FG215 have been assigned as values for
control of ABC. As a result, if a sales order is created with customer
10100001 with material FG215, and the delivering plant of the sales order
does not have sufficient stock of FG215 at the requested delivery date,
then the system looks for the alternative plants for the corresponding
material-plant combinations and selects the plant that can confirm the
maximum quantity at the requested delivery date.

Add Characteristics

Add Characteristics
Characteristic
. - - - - - - - - ---i ill ~
0 > Sales Document Item
Characterts1ic
0 v Business p3rtners
D v Sales Document Item
0 > Custo mer hie rarchy 1
D OeUvery Date and Quantity Fixed
0 > Cus.tomer hierarchy 2
'---'..i o Material Group
0 > Cus.tomei hierarchy 3
D Partial delivery at item l~el
0 > Customer hierarchy 4
D Checking Group for Availability Check
0 > SP Contract Rel.ord
D Delivery Priority
0 v Sold·TO Party
D Sates document item category
0 Customer Number
......+'-
~----- Material Number
0 Country KQy
> Pla nt (Own or External)

Configure Alternative Control v

Sales Order

Alternative Controls (1) Search Q Ill


Customer Numbor Materiol Number Substitution Strategy Execute ABC Created By

0010100001 FG215 ABC_Ol MROY

Figure 4.3 Configure Alternative Control for ABC App

Let's consider a scenario in which the ATP quantity for the material FG215 in
plant 1010, 1011, and 1020 is n il, 15, and 50, respectively. Now, if a sales
order is being created with material FG215 from delivering plant 1010 and

56
4 Alternative-Based Confirmation

the requested order quantity is 10, then the alternative plant will be 1011, as
shown in Figure 4.4. Also, if the requested order quantity is 30, then the
alternative plant will be 1020, based on the present building rule MAX_ON_
TIME_CONFIRMATION, which selects the plant that can confirm the maximum
quantity at the earliest time frame.

• • Standard Order Ava1lab11ty Control

v One.time ctelrvery Complete dtv' Delivery proposal ATP quanblies Scope of check Proo

Item 10 Sched line 1

Material FG215

SF No serial no batch

Requirement Segment:

Plant 1011 Plant 2 DE Munich

Original Plant 1010 Plant 1 DE Wal dort

Req delrvdate 30 . 03 . 2019 Open Quantity 10 EA

FIX Qty/Date Max Part Deliveries o

ne-time del. on req. del. dte

Oely/Conf Date: 30 03 20 I 9 I 29.032019 Confirmed Quantity I


omplete delive1Y

Oely/Conf Date 30 .03 . 2019 I 29.03 2019

ely proposal

Oely/Conf Date 30 .03 . 2019 I 29032019 Confirmed qty lol aj


Item 10 Sched line 1

Materta1 FG215

SF No serta1 no batch

Requirement Segment

Plant 1020 Plant 3 OE FranktlJrt

0<1glna1 Plant 1010 Plant 1 OE wandort

Req delf\fdate 30 . 03.2019 Open Quan\lty 30 EA

FIX Qty/Date Max Part Oelf\ferles o

One-time del on req del dte

Oely/Conf.Oate 30 03 .2019 I 29 .03 2019 1_______Uil...,.~ e .


Confirmed Quan\lty ...

Figure 4.4 Selection of Alternative Plant Based on the Stock Avai lability and Requested
Delivery Quantity

57
4 Alternative-Based Confirmation

Note
GATP in SAP APO requ ires a Business Transact ion setting in IMG configuration
for the sales order type for the RBA to be called from the corresponding SAP ERP
system. However, no such sett ing is required for ABC in aATP.

ABC as of SAP S/4HANA 1809 only supports the substitution of the deliver-
ing plant during the creation of sales order, with the following features:

• Building rule MAX_ON_TI ME_CONFIRMATI ON: Selection of an alternative plant


that can confirm the maximum quantity at an earlier date.
• Force inline substitution: The original plant is changed to an alternative
plant in the same line item.

Not e
GATP in SAP APO provides the option to create a stock transport order f rom the
substituted plant to the original delivering plant. However, ABC does not work
this way; ABC changes the delivering plant of the main line item of the sales
order wit hout any need t o creat e st ock t ransfer order.

4.3 Combining Alternative-Based Confirmation and


Product Allocation

ABC checks for the allocation quantity (product allocation) of the material
while substituting the plant and confirms the order quantity as per the allo-
cated quantity.

In our example shown in Figure 4.5, material FG215 has been allocated for 50
EA for the week beginning on April 29th. The sales order being created with
plant 1010 with requested quantity of 75 EA and requested delivery date of
May 5th gets confirmation for 50 EA per the allocation quantity set for the
week beginning April 29th. Figure 4.5 also shows that the original plant 1010
got changed to the alternative plant 1020 from original plant 1010 following
ABC functionality.

58
4 Alternative-Based Confirmation

,_
.' . Standard Order Ava1lab1 tty Control

v one-ume aell'Yery oe11very proposal ATP ~anoues scope 01 cneek Product attocanon More

Item 10 sc-ned 11ne l

MMetial FG.2 15

SF No senai no oaten
Requrement Segrnent

Plan.'! 1020 Plant 3 OE Frankt\Jrt

Onginat Plant 1010 Plant I OE Walleklrf

Reqdell\fdate: os. os.2019 Open Quantity 75 EA

Fee Oty/Oate Max Part OellYerles o

One-bme del on req. del. <Ae

Oely/Conl Oate 05 oo 2019 I 030520 19 Conl'll'mect OuantLty I


'
Dely proposal

De¥Conf0ate OS. 05 . 2019 I 03052019 connrmeo Qty so 0 I


Product Allocation Object v

ABCPLUSPAL ABC-PAL

SdealonRqe
21.04,2019 . 06.01.2019 e
Product Allocetlon Pt.&nnlng Data (1) S••«h
0 Sold-To Pllty • Cusl 15.04..2019 23.04 2019 06 '5.2019 13.05.2019 20.0S.2019 27.0S.2019 03.062019
Restricted
0 10100001 Avabbtity 80 100 50 60 0 0 0 0

-- Product Allocabon Conf11mooon ca1cu1auon

~ Allocation Object Priority Alloc Rate Check Date Time Type Backward C<ins.,.ption Forward Cons~tion Period Type
characteristic val ue cc.ibination
Hat. Avail .Date Check Date Requirement qty Confi...ation Date Confirmatil)n Qty A 1oc. UOM

QI ABCPLUSPAL l l , 000 0 0 ••
ASCPLUSPAL, 0010100001, fG21S
30 .04.2019 I 05.05.2019 I 75 OS.05.2019
I 50 EA

Figure 4.5 ABC Checks fo r Allocation Quantity while Substituting Plant

4.4 Limitations and Expected Enhancements


As of the SAP S/4HANA 1809 release, ABC has some limitations, as follows:

• ABC only works when creating a sales order, and not when changing a
sales order.

59
4 Alternative-Based Confirmation

• ABC changes the original plant to the alternative plant in the same line
item (i.e .. ABC does not create any subitem or propose multiple alterna-
tive plants).
• ABC isn't supported by the delivery or production processes.
• ABC is supported only for plant (or location) substitution, not for material
(product substitution).
• ABC does not work with backorder processing.
However, SAP is expected to provide several enhancements for ABC in
upcoming releases. The 1905 release of SAP S/4HANA Cloud and the 1909
release of SAP S/4HANA on-premise are expected to have the capability for
ABC to work when changing the sales order, and also to work with backorder
processing. The following additional enhancements are expected in the SAP
S/4HANA 1909 release:

• More options for the building rule


New building rules are expected to be released, such as the following:
- ON_TIME_CONFIRMATION: The plant that can confirm some quantity on
the requested delivery date will be a valid alternative plant. If multiple
plants can confirm some quantities on the requested delivery date,
then the plants will be sorted according to the confirmed quantity and
the plant that can confirm the maximum quantity on the requested
delivery date will be selected.
- FULL_CONFIRMATION: The plant that can confirm the full quantity will be
a valid alternative plant. If multiple plants can confirm the full quan-
tity, then the plants will be sorted according to the confirmed date of
the latest confirmed schedule line, and the plant that can confirm the
full quantity at an earlier date will be selected.
• More intelligence on the selection of alternative plant
If the multiple plants can confirm the fu ll quantity on the requested date
or have the same delivery proposal (i.e., same quantity with the same
schedule line date), then the alternative plant will be selected based on
the following sequences:

60
5 Backorder Processing

- Same country as ship-to party


For example, if the ship-to party is located in the United States, and if
the alternative plants are situated in the United States and Mexico,
then the plant(s) located in the United States will be selected.
- Same region as ship-to party
If the ship-to party is located in Texas, and the alternative plants are
located in t\<VO states (say in Texas and Arizona), then the plant(s) of
Texas will be selected.
- Shorter transit time
If the alternative plants also happen to be in the same region/state (say,
Texas), the transit time from the corresponding plant to the ship-to
party will be considered, and the plant with shorter transit time will be
selected.
- Overall delivery time (with transportation planning and pick and
pack time, etc.)
If the alternative plants are in the same country and state and also have
the same transit time, then the duration for transportation planning
and pick and pack activity will be considered, and the plant with less
overall delivery time will be selected.

Note
These advanced options fo r the building rul e and added intelligence for the
selection of alt ernative plants are already in the 1902 release of SAP S/4HANA
Cloud and hence expected in the 1909 release of SAP S/4HANA on-premise.

5 Backorder Processing
Backorder processing is a method of changing order confirmations based
on the available stock and business strategy (for prioritization). Essentially,
backorder processing releases the confirmed quantity for non priority orders

61
5 Backorder Processing

and allocates those quantities to priority sales orders or stock transport


orders. It's carried out either interactively or through a batch process. It can
also be run in simulation mode.

Backorder processing helps improve customer service and on-time delivery


for important sales orders or customers, resulting in higher revenue mar-
gins and enhanced service level and loyalty. In this section, we'll discuss
how backorder processing works, take a look at the configuration, walk
through relevant SAP Fiori applications, and explore additional features.

5.1 What Is Backorder Processing?


Backorder processing is the process of reperforming ATP to change the con-
firmation of orders in business scenarios such as the following:

• High-priority cu stomer order


Imagine the available stock is 100 pieces and a quantity of 80 pieces has
already been confirmed for some customers. Now, an order for 40 pieces
has been received from a premium customer (with high price and good
payment terms with good credit rating). The sales order from the pre-
mium customer will get confirmation only for 20 pieces. In this situation,
the quantity of 20 may be unconfirmed (or released) from previous sales
orders and subsequently assigned to the sales order from the premium
customer to confirm the order quantity of 40 pieces. This "unconfirms"
the quantity from the sales order of ordinary customer and subsequently
assigns it to the sales order of premium customer. This improves cus-
tomer service for the premium customer and results in better financial
health (increased revenue and margin) .
• Change in availability of stock
Say that an order was confirmed for a future date (10 days from now based
on the replenishment period), but now some stock has been received
(from a vendor or a return order from a customer). Backorder processing

62
5 Backorder Processing

can now be carried out to move the delivery date earlier. This improves
customer satisfaction with improved service level.
• Change in supply situation
If you have a shortage of raw materials or breakdown of production
machinery, resulting in a reduced supply of materials, then ATP needs to
be performed to balance the supply quantity with order quantity/confir-
mations. This improves delivery with fewer stockouts.
• Change in demand situation
If there are some cancellations of previously confirmed orders, those can-
celled order quantities can now be allocated to unconfirmed sales orders.
This improves customer satisfaction and the inventory situation.
In short, backorder processing helps optimize the dynamic supply and
demand situations in the order-fulfillment process, according to sales or
business strategies.

A simple backorder processing scenario is depicted in Table 5.1. Sales order


10057 was initially confirmed. A sales order from a premium customer
(10100001) for the same material was received later and remains uncon-
firmed, as there is no available stock. Backorder processing is run and
releases the material from normal priority sales order 10057 and allocates
the same to sales order 10094 for the premium customer with high delivery
priority.

Before Backorder Processing


Sales Creation Date Customer Material Delivery Order Confirmation
Order Priority Quantity Quantity
10057 April 20, 2019 10100005 FGll Normal 10 10
(02)
10094 April 23, 2019 10100001 FGll High (01) 10 0
Table 5.1 Confirmation of High-Priority Order after Backorder Processing

63
5 Backorder Processing

After Backorder Processing


Sales Creation Date Customer Material Delivery Order Confirmation
Order Priority Quantity Quantity
10057 April 20, 2019 10100005 FGll Normal 10 0
(02)
10094 April 23, 2019 10100001 FGll High (01) 10 10
Table 5.1 Confirmation of High-Priority Order after Backorder Processing (Cont.)

Note
There is a supply assignment functionality for the fashion industry, and its allo-
cation run has now been integrated with backorder processing in SAP S/4HANA.
Activation of business function SUPPLY_ASSIGNMENT_01 is a prerequisite to use
supply assignment.
This E-Bite is meant for the functionalities relevant for cross-industry, and
hence the supply assignment solution won't be detailed.

5.2 Configuration Basics


Most of the configuration settings for backorder processing in aATP are
done in SAP Fiori apps, but the following prerequisite IMG configurations
need to be set up for backorder processing on sales orders in aATP (see Fig-
ure 5.1):

• The availability check group must be activated for availability checks for
aATP in IMG menu path Cross-Application Components• Advanced Avail-
able-to-Promise (aATP) •Product Availability Check (PAC)• Define Available
Check Group O.
• The schedule line category must be flagged for availability check 8 .
• The requirement class must be flagged for availability check O.
• The fixed date/quantity must not be flagged on the sales order O.

64
5 Backorder Processing

Ch11nge View "Av11/111blflty Check Control": O verview


~ Now Entrlos Ill ~ !!) ~ ~ [i\

Av Desol>tbn
[""1,Y3 ",Crif A~TP r.o PAI ' !-
Tot.llSales
A
TotOIYReQs
,,.
BlockQtRQ ..,ched<
0
Aco.rn.., RelClidllan
3
Advn:edATP
A Aceive •

Ch11nge View "H11/nt11ln Schedule Line C11tegorles": Det111fs Chilnge View "Requirements Clilsses": Detillfs

~ New Ent•es ~ ~ If) l;:i () !ti ~ New Entries CD ~ "' ~ () !ti


Sched.ile cat. Reqntsdoss [0021 LQo:w/~v reqmt1--:

--..SSd.lt•
-
llet.'ay block
0 RQ()Jrements Assembly
- t tYJ)O !•011
GO ooods "''""~
R'iltem rel.f.ct.-. AvJM. Check 'c-IJ A-tYl)G 0
Movement Type l·Steo Req. tr¥'ISfet '<I Onle< cosliig 0
Q-der T¥Qe n O P.reQ.delsched AJocatlcn h:I. AUtomatlc c:h'oo 0
Item cateo:rv D Oext."""'. o1anniio Prod.Oloc•tbl 0 Soedal Stock 'l
Acct AS$0T'lt cat
,..,_
tnd.1eQ,reci.Jc.tn 0 O.dE< TYl)G D
u:>date Sched. li"les
MvT !SS. V~. 9 T
R
Cl
.., t.l>date O \!Pd. Sdled 0 Avai,CQO'lJOOE!f"lts 0

Sl>ec.lss. V;J.. SIT D


Transaction tow
1ncoo0.orocsd. f30' Gener.ii Sdied. '-""

~Re<1 £A~
I R)AvalOOlty ,
0 Prod.Oloc" ion

Chilnge st11ndi1rd Order 119: Iten1 Diltil

H • ~~I UU iOO <$J ?:o ~ ~ EJ ~

~
5"" Doc""""' Item [10 Item C"eo<>Y ['TA11 l St.rdard Item
r,--~~~~~~~-'-----'----i
Material FGlS FGAATP Test lSBOP

tfse A , Sates e

I" ed Date .-.cl Q" ()der Qwntity •Ul


~edQty ='5
. 1'

Figure 5.1 Basic IMG Configurations for Backorder Processing for Sales Order in aATP

5.3 SAP Fiori Applications


There are five SAP Fiori apps for backorder processing in aATP as of SAP
S/4HANA 1809. Sequential steps (process flows) for the configuration of
backorder processing are shown in Figure 5.2.

Note
The SAP HANA rules framework is a prerequisite for backorder processing in
aATP, and it may need an addit ional license. Refer to SAP Notes 2481716 and
2400537 for details and setup informa t ion.

65
5 Backorder Processing

As an additional prerequisite, VOCABU LARY_SERVICE also needs to be activated


through Transaction /IWFND/MAINT_SERVICE.

ATP Backorder Processing

Configure BOP Configure Custom Configure BOP Schedul e BOP Run Monitor BOP Run
Segment BOP Sorting Variant

~ [_,,,· ti ~ !»<Yi 0

,'' .......
~

J..'
'
Assign backorder -~ Schedule backorder ~ Review the result
Define rules t o

(optional)
" " ' Define rules to " " '
sort requirement s / priorit ize
requirements
/
confirmati on strategy sim ulation or real
to;/
processing segment wi~ processing for variant
update
of the backorder
processing run

Figure 5.2 Process Flow for Configuration of Backorder Processing with SAP Fiori Apps

Note
Similar to prerequisite settings for SAP Fiori apps for product allocation as listed
in Table 3.3, the settings listed in Table 5.2 also need to be established for SAP
Fiori apps for backorder processing to be displayed in the SAP Fiori launchpad.

SAP Fiori App Activation of Activation of Assignment of


ICF Nodes: OData Services: User Role:
Transaction SICF Transaction Transactions
/N/IWFND/ PFCG, SU02
MAINT SERVICE
Configure /sap/bc/ui5_ui5/ ATP BOP SAP BR ORDER
backorder pro- sap/atp_abopvarsl SEGMENT SETUP FULFIL LMNT
cessing segment MNGR
Configure /sap/bc/uiS_ui S/ ATP BOP SAP BR ORDER
backorder pro- sap/atp_abopvarsl VARIANT SETUP FULFIL LMNT
cessing variant MNGR

Table 5.2 Prerequisite Settings for Backorder Processing SAP Fiori Apps to Appea r in
SAP Fiori Launchpad

66
5 Backorder Processing

SAP Fiori App Activation of Activation of Assignment of


ICF Nodes: OData Services: User Role:
Transaction SICF Transaction Transactions
/N/IWFND/ PFCG, SU02
MAINT SERVICE
Monitor /sap/bc/uiS_uiS/ ATP MONITOR SAP BR ORDER
backorder pro- sap/atp_abopvarsl BOP RUN FULFILLMNT
cessing run MNGR
Schedule /sap/bc/uiS_uiS/ APJ JOB SAP BR ORDER
backorder pro- sap/nw_aps_apj MANAGEMENT SRV FULFILLMNT
cessing run MNGR

Table 5.2 Prerequisite Settings for Backorder Processing SAP Fiori Apps to Appear in
SAP Fiori Launchpad (Cont.)

The functions for each of the five SAP Fiori apps for backorder processing
are described in the following sections.

Configure Backorder Processing Segment


If the total requirements in sales orders are greater than the available stock
(or capacity), then the requirement s are selected (filtered) and prioritized
(sorted) to confirm the sales orders and/or stock transport orders based on
the business prioritization strategy, as set up in the Configure Backorder
Processing Segment app, shown in Figure 5.3. The backorder processing seg-
ment can be created, changed, or displayed in this app and then assigned to
a backorder processing variant, as described in the Configure Backorder
Processing Variant section. The CUSTOMER_PREMIUM backorder process-
ing segment has been created as shown in Figure 5.3, with specific sold-to
party, material, and supplying plant as selection criteria 0 , and order cre-
ation date and delivery priority as sort attributes set in ascending order f),
which you can add to or delete e.

67
5 Backorder Processing

8 < tlil & BOP Segment Definition v

CUSTOMER_PREMIUM

r
Seteaion Criteria

""Aecr.*emtnt Alter 0
SOido 7b Parry Of the ATP Document cootalns '101 QQOOS' :ind Matedal Of tile ATP Documenf coolalns :EG.lJ'. 3.nd Plant Of the ATP Doctlment CONail'IS :J..!l1D:

Prioritizer

0 OAOERCREATIONOATE Ql.j.l.jl,fl O.sctndhg


0 IOELIVERVPRIORmi 6J - ibj.!.\.!\,g O.sctndr.g

Figure 5.3 Filter and Sort Criteria in Configure Backorder Processing Segment App

Standard fields for selection (filter) for backorder processing of a sales order
in aATP in SAP S/ 4HANA release 1809 are listed in Table 5.3.

Sales Order Sales Order Item Schedule Line Item


Item cat egory Mat eria l Supplying plant
Storage location Batch Group type
Delivery group Complete delivery Created by
Materia l ava ilability date Requested delivery date Order creation date
Sold-to party Sa les organization Distribution channel
Division Sa les document type Material group
Delivery priority Shipping condition Customer grou p
Checking group Sh ipping point Delivery date/quantity fixed

Table 5.3 Standard Fields for Selection (Filter) for Sa les Order in aATP, 1809 Release

SAP S/4HANA, as of t he 1809 release, also supports backorder processing for


stock transport order. Some of the key fields for filtering for stock transport
order are as follows:
• Document type • Item category
• Purchasing organization • Delivery priority
• Purchasing group • ATP category

68
5 Backorder Processing

Standard fields for sorting attributes for both sales orders and stock trans-
port orders are displayed in Figure 5.4. Circular labels G, 8 , and 9 show
snapshots from the list of sort attributes from the SAP Fiori app.

G Sort Attribute

Search

Sort Attnbute Sort Attrlbti.e Oe1Crlpdon

ATPRELEVANTDOCSCHEOULELINE Schedule Line In a Document Included in ATP Checks

ATPRELEVANTOOCUMENT Oocumem Included In ATP Checks

ATPRELEVANTDOCUMENTCATECORY Categoty of a Document lnduded in ATP Checks

ATPRELEVANTOOCUMENTITEM l.int Item i"I a Document lndl.JICMd i"I ATP Checks

BATCH Batch Numbtr

CREATEOBYUSER NM'le of Person who Created the Object

CUSTOMERGROUP Customef Gr°'4)

OELIVERYGROUP Oetlve.ty Group (l tet'l'IS are delivered to~thff)

OELIVERYPRIORrTY Ottivtty Prioiity

OISTRl8UTIONCHAHNEL Ob:tribucion Ctwnntl

FASHIONCAHCELOATE Cancellation Date


ISSALESOOCUMENT ATP Document Is a Sales Document

ISSTOCKTRANSPORTORDER ATP Oocuimnt Is a Stock Transport Ord«

Seateh
f) Sort Attribute SALESDO<:UMENTIYPE

SALESGROUP
e Sates Document Type

Sates 11'°'4>

SALESOFFICE Sates office


ISSTOCKTRANSPORTOROER ATP Document ts a Stcx:k Transport Order
SALESORGANIZATION Sates Org1ni2ali0n
MANOT Client
SOOOCUMENTCATEGORY SO Ootum~ C'1tegory
MATERIAL Materlal Number
SHIPPINGPOINT Sh.pplng Polnt/Rec:•iving Point
M.ATERIALG.ROUP Mintrill Group
SOLOTOPARTY Sotd·To P<irty
ORDERC.REATIONDATE ~t• on wfiiieh lht rtc0rd WI!$ O'&l'tf'd
STOOEUVERYPR:IORITY Dell\lety PrlMty
ORGANIZATIONOIVIStON Division
STORAGElOCATION Storago locMiCJ.n
PROOUCTAVAILABILITYOATE Ma;eriat Staglng!Avalabil«y Date
SUPPLYINGPlANT ?\ant (Own or External)
PURCHASEOROERITEMCATEGORY Item category In p.xchaslng document

PURCHASEOROERTYPE Pu1chaislng Document Type


PURCHASINGGROUP Pu1chais.ing Grovp
PURCHASINGORGANIZATION Pu1chaoslng o rganization
REOUESTEOOELIVERYOATE Sched\Ae Une date

SALESOOCUMENTrTEMCATEGORY Sates docum.ru item eateg<>ry

SALESOOCUMENTTYPE Sales Document Type

Figure 5.4 Standard Fields for Selecting Sort Attributes for Sa les Order and St ock Transport
Order

Note
Backorder processing, as of the SAP S/4HANA 1809 release, does not support
custom fields for fi ltering and sorting attributes. SAP is expected to provide t he
option for custom fields in a future release of SAP S/4HANA.

69
5 Backorder Processing

Configure Backorder Processing Variant


A backorder processing variant is created with the Configure Backorder
Processing Variant app, and the backorder processing segment (created
and described in the Configure Backorder Processing Segment section) is
assigned to a confirmation strategy in the backorder processing variant, as
shown in Figure S.S.

Variant Settings

General Information

*Variant Name: ~(tro


_ P_
GA _L_o s_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _~
_IN

Variant Description: SOP with GAIN and LOSE strategy

Execution Options
0
*Document Types: sm~ Documents
l
• checking As: Sates Order (Business Scenario: A)

Configuration Options

Exceplion BehaviOf: Stop Failed Material·Plant Combinations v

FaUb&ck Varlart Name:

Gtobal Segment Name:

BOP Variant Definition v

BOPGAINLOSE
SOP with GAIN and LOSE strategy
m Delete Copy S.,·11Aate v Show Last Runs f!:'

Document Types: Sales Documents Exception Behavior: Stop Fa!led Materlal·Plan1 Combinations
Cheddng As: Sales Order (Business Scenano: A)

GAJN LOSE

Segment Name e Setecrion Criteria

SOLOTOPARTV of the ATPOOCUMENT contains ' 10 10000~' and MATERIAL of the ATPDOCUMENT contains 'FG14' and
CU STOMER_ PREMIUM
SUPPLVINGPLANT of the ATPOOCUMENT contains '1010'

LOS E

Segment Name o Selection Criteria

SOLOTOPARTY of the ATPOOCUMENT contains '10100004' and MATERlAl of the ATPOOCUMENT contains 'FG14' and
CUSTOMER_CREOITBLOCK
SUPPLYINGPLANT of the ATPOOCUMENT contains '1010'

Figure 5.5 Configure Backorder Processing Variant App with Gain and Lose Confirmation
Strategy

70
5 Backorder Processing

You can see the option to select the sales order and/or stock transport
order 0 , your backorder processing confirmation strategy 0 , your back-
order processing segments (0 and 0 ), and the Sim ulate option 0 , which
you can use to monitor and run backorder processing.

Backorder processing confirmation strategy is a new concept in aATP; it


doesn't exist in SAP ERP, nor in GATP in SAP APO. The simple use of confir-
mation strategy eliminates the requirement o f complex configurations of
GATP in SAP APO. Backorder processing confirmation strategies are de-
scribed with relevant business scenarios in Table 5.4.

Confirmation Processing Definition Business Scenario


Strategy Priority
Win 2 Requested quant ity will Customer organizing a
be f ully confirmed sales promotion event
Gain 3 Previous confirmations Premium customer with
are ret ained and may high price, loyalty, etc.
improve
Redistribute 4 Confirmations may gain Regular customers
or lose
Fi 11 5 Will not gain, but can Customer with yearly
keep the same or lose contract without specific
previous confirmations delivery schedule
Lose 1 Will lose all confirmations Customers with credit
block

Table 5.4 Backorder Processing Confirmation Strategies

71
5 Backorder Processing

The important features that need to be considered while setting up the


backorder processing segment are as follows:

• The assigned backorder processing segment must have a confirmation


strategy.
• Multiple backorder processing segments can be assigned with a single
confirmation strategy.
• There can be a maximum of five confirmation strategies (win, gain, redis-
tribute, fill, or lose).
• Requirements with a lose strategy lose their confirmation first, as they
have the processing priority 1, as shown in Table 5.4; then the require-
ments with the win strategy are processed.

Backorder processing can also be ru n in the background, either in simula-


tion or direct update with the Configure Backorder Processing Variant app.
The Configure Backorder Processing Segment app can be navigated from
the Configure Backorder Processing Variant app.

Not e
A backord er processing variant need not have all the five confi rmation strate-
gies like backorder processing variant BOPGAINLOSE, as shown in Figure 5.5,
w hich has only two confirmation strategies: GAIN and LOSE.

Also, a backorder processing variant can have multiple backorder processing


segments with same (or single) confirmation strategy (see Section 5.5).

Schedule Backorder Processing Run


Backorder processing can be run immediately (using the Start Immediately
option) or through a batch job with the Schedule Backorder Processing Run
app for a specific backorder processing variant (e.g., Backorder Processing
GAIN LOSE), as depicted in Figure 5.6.

Backorder processing also can be run either in simulation or direct update


mode with flexible scheduling options. Figure 5.6 shows various scheduling
options/parameters for the backorder processing run.

72
5 Backorder Processing

ATP: Backorder Processing GAIN LOSE

GENoRAL INFORMATION SCHEDULING OPTIONS PARAMETERS

*Job Temp(;ite: ATP: 8.ckorder Proct$$irlg Oefavlt 6l


Job Name: ATP: Backorder Processing GAIN LOSE

Scheduling Options

Oeme Recurrence Pattern

Sta.rt lmmedla1ely: 0 Rewnen<:e Pattern: Single Run

Start: ; 01,04.2019, 08:ooj ra j


lime Zone: C•nual El.lf()pt

Job Start (local Time): ~ion ~r 01 2019 08:00:00 GMT•0200 (Central European
Summ•r Time)

Parameter Section

BOP Variant Options

Creation Date: dd.MM.yyyy Parallel Doc. Update Prof1 : o".l


Created by: 0
Last Chan,ge Date: dd.MM:yyyy 0
Changed by: 0
*Variant Name: SOP\VINGAINlOSE 6'

For~ Log: 0
Granularity: Nothing v

ScheduCing Information

Statt lmrn.tdlatety: 0
Job Start: 01.04.2019, 08:00 CG Central Europe Ql
Job Start (local Time): Mon Apr 01 2019 08:00:00 G~~T+-0200 (Central EUJopean Summer Time)

Recurrence Pattern: Daily v

Every: l O&y(s)

End: None v

On Non-World~ Day: No restrict ion v

Ca~ndar: Ge-rm.1ny (Sta~ard)

ClK] Rn~cl Scht.-dul.-ig Options C<i~I

Figure 5.6 Schedule Backorder Processing Run App to Execute Backorder Processing

73
5 Backorder Processing

Monitor Backorder Processing Run


The results of the backorder processing run can be evaluated with the Mon-
itor Backorder Processing Run app. Table 5.5 shows the scenario for confir-
mation of sales orders before the backorder processing run.

Type of Customer Customer Sales Order Required Required Confirm


Quantity Date Quantity
Premium customer 10100005 10000679 40 Apri l 3 0
Customer on credit block 10100004 10000677 40 April 3 40

Table 5.5 Scenario before Backorder Processing Run

Backorder processing variant BOPGAINLOSE, as set up in Figure 5.5, was run


with the Monitor Backorder Processing Run app; the result of the backorder
processing run is displayed in Figure 5.7. Both the direct update mode 0 and
the simulation mode O are shown, as well as icons that indicate an improve-
ment in confirmation 0 or a loss in confirmation O.

8 < ~ 1:':!£' Monitor BOP Run v

A.II (3) 80PCAl'4l0SE ®


,..,
v ©

Sc•rtKt Compto<Od
Proc.ulna
Status
Rf\qUlrtm9tlts
Reqtk•n'leMS
Fi.Aly Cont'itmrtd
On·Time
Roq..Ar•rn•nts
Fu11y C<infinMd ....
BOPG.AINlOSE 0 MROY 30.03 2019.14:43 30.03.2019, 14 4J
0 2 '°" ., so .. '°" ., '°" si.....Loa
A
BOPG.AINlOSE
Slmul.Won V'
MROV 30.03 2019, 14:33 30.03.2019, 14 33
0 2
'°" .. '°" '°" .. '°" Show l og

8 < ti! &" Monitor BOP Run v 0.


BOP Run Ust I BOPG.AJ NI.CSE I
Materia l: FG14, Plant: 1010 si.....v"""' [!l

R9<11,11rern9nb: 2 ProcffM<lc 2 Roquiremeru Fully Conlltmed On°TIIM: 50%


ProcttWlg lswes: o Not Processed. o ReqUiremencs FuUy Confim'l@<f ~

All (2) P~g IWJH CO) CoM!rmadon l»Vff (1) 0. ©


Maoterial ?tint
Conflr1N1
ion RtcipMnt Ewtilst Cotllrtnation Overall Confirmation
Pr0CH1in
g Sca.tus
....,
Confm\

Scrtnegy Sta<us
03.04 2019 ]'. 03.04.2019 ]'. ()3._0,S,2019
10000679 1010000
000010 (0001)
FGl4 1010
"''" 5
CUSTOMER_ . tCElJ
•O l'C
OPC ~ 40PC (CEl) (<:El) @)
0 PC }I 41) PC OPC }I 4QPC

03.04.2019
10000617
000010 (0001)
FG14 1010
1010000
4
CUSTOMER_,. tCEl)
40 l'C
OPC ~ OPC
03.04 2019)1
(CET)
40PC )l 0PC
(CEl)
40 Pe
'
)I 0 ot:
[@]
Figure 5.7 Result of Backorder Processing Run with Mon itor Backorder Processing Run App

74
5 Backorder Processing

As you can see from the backorder processing result, the quantity (40 PC)
initially confirmed for sales order 10000677 for a customer with a credit
block has been released due to the lose confirmation strategy; that stock
has been allocated to sales orders 10000679 using the gain confirmation
strategy.

Note
The win confirmation strategy requ ires the full confirmation of the quantities
on the requested date. Other strategies, like gain, red istribute, and fill, al low
partial confirmations.

Configure Custom Backorder Processing Sorting


Sorting sequence for the prioritizers can be optimized with the Configure
Custom Backorder Processing Sorting app. Refer to Figure 5.8, in which the
backorder processing segment ALL_OTHER_CUSTOMER_2 has two prioritiz-
ers: ORDERCREATIONDATE and SOLDTOPARTY. Dates in ORDERCREATION-
DATE can be sequenced numerically (chronologically); however, the same
numeric sorting should not be applied for SOLDTOPARTY, hence SAP has
provided this SAP Fiori app (in the 1809 release of SAP S/4HANA) for
custom sequencing of sorting attributes (prioritizers) in the backorder
processing run.

Note
Custom backorder processing sorting is optional for backorder processing setup
(i.e., not mandatory setup for backorder processing).

Sorting sequence CUSTOMER_SORTING has been created for sold-to parties


so that the sales orders are sorted for backorder processing corresponding
to the sold-to parties, as in the given sequence.

75
5 Backorder Processing

BOP Segment Definition ........

ALL_OTHER_CUSTOMER_2
AU «lwf customen., ~I fitter ..W:h Ma1erial FG21 In pbot 1010

CrNted By: Cha"Sed8y:


CtN ted On: 04.04.2019, 08:46 Chaf'8ed On: 04.0r4.2019, 08-:47

Selection Criteria

Requlromtnt f il.i:M

Marer;a,' ()( tlle ATP DoclJrnef)I' is equal to '.fG.2J.: ANO P:a111. or ~ATP Oocume!lf Is equal 10 :1.QJ.Q:

Prioritizer

Son Order

ORDERCREATIONDA"ft w1.: !§. I


I Oescet'd no

SOLOTOPAATY I...CUSTOME~SORTllKi I >

Sequence v

CUSTOM ER_ SORTING

0. C•I

l 0010 100011

2 0010 100005

3 0010100008
4 All othets

Figure 5.8 Custom Sorting for Prioritizers with Configure Custom Backorder Processing
Sorting App

A backorder processing result with a custom sorting is displayed in Figure 5.9


for a backorder processing variant with redistribute and lose strategies. Sales
order 10000690 lost all its confirmation due to lose confirmation strategy,
and those 40 PC have been redistributed to a sales order with given se-
quence of sold-to parties, as shown in Figure 5.8.

76
5 Backorder Processing

Monitor BOP Run v a.


BOP Run List / BOPAEOISTAIBUTELOSE I
Material: 1'<321. Plant: 1010

Procos.sing Issues: 0 Not Processod 0 A~~ fully Conllrmed: 50'M.

AU (4) Proc9$q liwts (0) Confirmation 1$$Uts (2) S...Ch a. @

10000691
000010(0001)
FG21 1010
Conllnno<

""
Stt•ttgy

...
Redistrlb
R~nt

1010001
1
Segmtt'll N.ame

ALt.....OTiiER_..
·-·
05.04.2019

2S""
On-T.nt C<>dirmatien

OPC JI 2'PC
Eartle" Confirn'labOn

,. 05.0C.20
19
OWreU Confirmation

;i OS.04.20
19
Proces-M
'Sl>tus

0
Contltm
atiOn
S<•lUS

[QJ
0 PC J' 25 PC 0 PC }l 25 PC

.. 05.<M,2019 }I 05.04.20 ;i OS.04 20


100006.92 R~1$ttlb 1010000
000010(0001)
FG21 1010
5
ALL OTHER_
10""
OPC JI l OPC 19 19
0 [QJ
0PC " 10PC 0PC Jl 10PC

10000693 05.04.2019 11
M.OC.20 " OS.04.20
Redistrib 1010000
000010(0001)
FG21 1010
.... 8
Alt,_OTHER_.. _
10""
OPC JI 5PC
OPC }l 5 PC
19 19
Q pe ;A 5 pe
0 @)
10000690 05.04.2019 OS..04 20 '.:ii 05.04 20 '»

000010(0001)
FG21 1010 Los+ lOl OOOO
4
CREEOITSLO.
40 ""
OPC -+ OPC 19
40 PC '» OPC
19
'()PC '» OPC
0 @)

Figure 5.9 Backorder Processing Result w ith Custom Sorting Sequence

5.4 Global Filter


A global filter defines the overall superset of requirements for a backorder
processing run. It can be used for the overall selection of regular customers
for materials with specific plants. Figure 5.10 highlights the following points
about global filters:

• Backorder processing segment ALL_ OTHER_ CUSTOMER is a global filter


representing the regular customers for material FG14 of plant 1010.
Requirements selected by the global filter (the large circle) but not
impacted by any other backorder processing segment (such as premium
customer) are assigned to the confirmation strategy redistribute (similar
to other backorder processing segments).
• Different types of customers are set with specific confirmation strategies.

77
5 Backorder Processing

Gain

Premium
customer

Customer with
Redistribute

All other customers


B
Customer with
promo event for material FG14 credit block
in plant 1010
(globa I filter)

0
Customer with no
fixed schedule

Figure 5.10 Concept of Global Filter

If a backorder processing variant has a global filter (like ALL_OTHER_CUS-


TOMER), then other backorder processing segments need not be defined for
a specific material-plant combination, as in the case of backorder process-
ing segment PROMOEVENT_CUSTOMER in Figure 5.11.

8 < tJ1i' ~ BOP Segment Definition v a.


PROMOEVENT CUSTOMER
Custome1 with Promo event
.. Show Related Variants (3) Delete Copy EC

Created By: Changed By:


Created On: 17.11.2017, 06:19 Changed On: 28.11.2017, 11:48

"
Selection Criteria

Requirement Filter

sora- To Pa'!'f 01 the ATP oocumeni contains '!QJOOO!l'

Figure 5.11 Customer with Promo Event

78
5 Backorder Processing

Table 5.6 lists different types of customers with specific confirmation strat-
egies and sorting behaviors for a backorder processing run with a global
filter.

Type of Customer Confirmation Sorting Behavior with


Strategy Confirmation Strategy
Customer with promo- Win Not sorted; they have prio rity
tion event
Premium customer Gain Sorted by requested delivery date
Customer with no fixed Fi II Sorted by order creation date
delivery schedule
Customer w ith credit block Lose Not sorted
All other customers with Redistribut e Sorted by order creat ion date
specific material (FG14) (Set as g lobal fi lter)
and plant (1010)

Table 5.6 Different Types of Customers Set with Specific Confirmation Strategies and Sort-
ing Behaviors

Figure 5.12 shows the process for creation of a global filter:

0 Backorder processing segment ALL_OTHER_CUSTOMER is created first


with the Configure Backorder Processing Segment app.
9 Backorder processing segment ALL_OTHER_ CUSTOMER is then defined as
a global segment and assigned to a confirmation strategy (redistribute)
in the header of global filter GLOBAL_FILTER.
8 Global filter ALL_OTHER_CUSTOMER appears at the top of the backorder
processing variant.
0 Other backorder processing segments with respective backorder pro-
cessing confirmation strategies are then assigned to global filter variant
GLOBAL FILTER.

79
5 Backorder Processing

Varian1 Settings

*Variant N.amo: GlOBAL_FllTER

Variant Oesalpdon: Global Fitter

Execution Options

BOP Segmen
*Document Types: S.sles Documents Stoek Transpon Orders

"Chf.cU!g A.$: Salff Otdtf (Sushts.s SUnarlo: A) ALL_OTHER_CUSTOMER


All och•r ~In GloWl fitter with Materl.t FG15 in planl 1010

Configuration Options
Creac.ecl By:
Cre-ated On 17 ll.2017, 06:30
v

fall.bade Variant Name:


8
Al t._OTHER_CUSTOMER
Selection Criteria 0
Remalnloe Item$: Redistribute v Requir~ Fi!'tt r

Cl~

BOP Variant Oetin-tion v 0.


GLOBAL_FILTER
Global Filtf'I'

Oocumenc Typn: Sales ~uments Exception Behav.or Stop F.-led M¥.erial-~nt Combinations
e
G&obat Segrr-ent Namt'. All...OTHER..CUSTO.
Cht<kinS As.. Salos Otdof (81AiAKS Scenario: A) R~m3ini"B 11~.ns.: Redi~ribut~

wi "~-GAJ
i•l.... ~"~-'-"-L~-L....,
osE~
+
Segment Name Selecclon Cri(erla

D PRO>.iOEVENT_CUSTOMER Q> SOLOTOPAATY of the ATPOOCU>.•ENT c:cntaln-; '10100011' >

GAIN

SegmeftlName Seteaion Criteria

PREM IUt.~CfJSTO'AER 63 SOLDTOPARTY ol the ATPOOCU'4ENT <ontaird '1010000!>'

Figure 5.12 Process of Creating Global Filter for Backorder Processing Run

Table 5.7 describes the scenario for sales order conformations with different
types of customers for all sales orders created on March 30th. It shows that
certain non priority sales orders (like 10000682} have confirmed quantities,
whereas some sales orders (like 10000687) with priority customers do not
have order confirmations.

80
5 Backorder Processing

Type of Customer Customer Sales Order Required Required Confirmation


Number Quantity Date Quantity
Customer with 10100011 10000687 25 April 1 Nii
promo event
Premium customer 10100005 10000686 10 April 3 Nii
Customer on credit 10100004 10000682 20 April 9 10
block
Customer without 10100002 10000683 15 April 5 5
specific schedule
All other customers 10100001 10000684 10 April 1 10
10100008 10000685 5 April 8 25

Table 5.7 Scenario for Sales Order Confirmations before Backorder Processing Run

Figure 5.13 shows the result of a backorder processing run (for the scenario
in Table 5.7) as displayed in the Monitor Backorder Processing Run app. It
indicates the following:

• Sales orders with lose and fill strategies have lost their confirmation quan-
tities.
• Sales orders with win and gain confirmation strategies have gained in
order confirmation quantities.
• Sales orders with the redistribute confirmation strategy have retained
their order confirmations.

Note
As of the SAP S/4HANA 1809 release, the date also includes the time zone of the
plant for better clarity. Previously, the date without the time zone was a bit con-
fusing if users are in different t ime zones.

81
5 Backorder Processing

MonrtOI' BOP Run v

BOP Ru'I List I


GLOBAL_FILTER
~-
USff~_MROY Started; 30.0J..2019.17.34 Re<J*emerts 6 f'llOces.wd 6 ~Fl.AlyCO"lfrmedCJn.Tl'l'le' 6~
COll1*tecl·J003.2019.17:34 ~ISSUfi$.; Q HotPfOcmit<tO ~IWyton!Ymed-6.,_

Al (1) Prouswc •~ (O) eottirmc.bOl'I •~ (1) a. <i>

1010
• 67-.... 67~

BOP fb.r'I Ust / Gl.08Al_FILTER I


Material: FG14. Plant: 1010

Conrwmabon 1$kll'S (2) a. <i>

--
Proc.swg '""'" (0)

............ ......... """


,...,...,
000010 (0001)
FG14 1010
~

"'-
''""I>
- ·- 101000U l'ftOMO(V{HT
01.04.2019(C:ET)

""'
n-r. Cor<•INtlon
On>

OPC " 25PC


.....,..,...,..,_
> OL.04 2019
(CE1)
0PC -" 25PC
OW.Jll Gonf..!NliOn

,. 01.04 2019
(CET)
OPC 7' 25 PC
.....
Pr0Cf$V'lg

0
""""""'
kin St.Jtus

@)

,_
10000•. .
QOOOIO (0001)

000010 (0001)
''"'
FG14
1010

1010
.........

10100005

10100008
PREMIUMCUST ..

M..t.._OTHEJLC.
03.04 2019(CET)
IOOC

01.04.2019(C£T)
10""
OPC ,. 10PC

OPC > IOPC


JI' 0304 2019
(CET)
OPC > lOPC
,. 03042019
(GET)
0PC "' 10PC
01.0S-2019 ... 01"04 2019 0 1 04.2019 ...01 04.2019
(GET}
10PC -t 10PC
(CET) (CET) (GET)
10PC-+10PC
0
0
@)

@)
10000685 .......... >LL
08.04.2019(C£T) oe.c.i 2019 ... oa.04 2019
(CET) (<ET)
oe.04 2019 ...oe 0...2019
(CET) (CET)
0 @)

.
FG14 1010 10100001 OTHER C OPC 5PC
• 50( l"


(WX)OlO (0001) 5PC-t5PC 5PC ... 5PC
05.04.2019 ... 05.04.2019 'lo
OX>OlO (0001)
FGl4 1010 AU 10100002 """"' ......., 05.oA.2019(CET)
150( OPC-+OPC (CET)
l5PC " OPC
(CET)
15PC 'lo OPC
0 @)
1...,..., 0904 2019(C£T) 09 ()rt 2019 " 0904 2019 ...
@)
000010 (0001}
FG14 1010 10100004 GR£ECl1"8lOC.
20PC
0PC.,.0PC (CEl)
20 PC 'lo OPC
CCETJ
70PC "" OPC
0
Figure 5.13 Result of Backorder Processing Run with Global Filter

Global filters can be of t wo types:

• Inclusive
A set of requirements that conform to the selection criteria are included
in the backorder processing run (the scenario described in this section
corresponds to an inclusive global filter).
• Restrictive
A set of requirements that conform to the selection criteria are excluded
in the backorder processing run. Global segment ALL_OTHER_CUSTOMER
has been set as rest rictive by selecting Ignore for Remaining Items 0 , as
shown in Figure 5.14. Notice that this segment doesn't appear in the Seg-
ment Name column, since it has been ignored/restricted f).

82
5 Backorder Processing

Configure BOP Variant v a.


GLOBAL_FILTER5
Gtobal f ilttf 5
m Delete Copy Stmulate v Show La5t Rum (1

Docun~t Types: Sar.H Doeumerws ExcepciOn Behavior. Stop COf'l'lpleletyo Global Se~enc Name- ALLOlliER_CUSTO...
Checking As: Stte-:s Order (BUSiness Sce-natto: A) Remaining Items: Ignore I
A fl

Monitor BOP Run v

BOP R\nUst I GL.OeM._fiLTE~/


Material: FGl4, Plant: 1010

~emerts•.t Processed:O ~ementsFUlyCOr6medOn-lhe•SO'f6


Proc:imini: ~wes: 4 NQt. Procnw<t- O ~emem FUlyCornm!!d- ~

Rfql#ement

10000687
All (4) ~1$$Vit${4)

......... """' ""'"'"""


on Strate()'
~ 1 '!.Wt$(2)

- ~ t:atne

·-
0104.2019
On-Tne Conhmabon ,.._""',,....,,,
-
o-• Conllrm;ibon "'"""'8
St>tvs
0. €>

'°""""'
"'"St>tvs

000010 (0001)
FG14 1010
"" 10100011 PROMOEVE:HT_.••
51 oc
OPC 4 OPC
OPC .+ OPC OPC -+ OPC 0 @]
10000686 03.C>l 2019
000010 (0001}
FGl4 1010 Gas> lOt()O(XIS PR£,.,IU•ACUST .•.
10"'
OPC -+ OPC
OPC ... OPC OPC -+OPC 0 @]
1000068.J 05.0.1.2019 0504.201 .. 05.04 201 05.04 201 ... 05.04.201

000010 (0001)
FGl4 1010
"' 10100002 NOSCHEDtA.E_..•
1SPC 15PC -+ 15PC 9 9 9 9
0 @)
15PC ' l5PC tSPC. -+ 15 PC
10000682
FGl4 1010 ..... 10100004 atffOITBLOGK ..
0904.2019
20PC -+ 20PC
09.0t.201 .. 09.04.201
9 9
09.04.201 ... 09.04.201
9 •
0 @)
000010 (0001)
'°"' 20PC .+ 20PC 20PC -+ 20PC

Figure 5.14 "Rest ricted" Global Segment

The backorder processing result of global filter GLOBAL_FILTERS, as dis-


played in Figure 5.14, shows the following:

• There is no backorder processing segment ALL_ OTHER_ CUSTOMER, as


that has been excluded.
• Backorder processing has been stopped, as the requirements (sales
orders) with win and gain confirmation strategies did not get confirmed.

5.5 Fallback Variant


Backorder processing runs stop immediately in the following situations:

• The requirements can't be fully confirmed on time with win confirma-


tion strategy.
• The current confirmations (date and quantity) can't be retained with gain
confirmation strategy.

83
5 Backorder Processing

In the scenario described in Table 5.7, if the order quantity for sales order
10000687 is increased to 51 PC, then the backorder processing run stops
immediately, as sho\.vn in Figure 5.15, as the sales order with win confirma-
tion strategy does not get confirmed.

l\ion tor BOP Run v

90P R\a'l l.ist /


GLOBAL_FILTER
...........
User N.wne. MROY Started: 30.0l.2019.19:l2 Recµrements: 8 Pfocfl:sed•O Req.iifel:nents NllyConfnnedQn.Tme• 67'41
~ed: 30.03 2019. 19'32 Pfocessi'lg hwtS: 6 Hoe Proomed: 0 Rf4jlranent5 Nty CO!fttned: 671Wt
A /J
t.lAl"EAIAL·PlANT CQt,flRMATlON STRATEGY RECIPIENT

All (1)

FG14 1010

Moo tor BOP Run v

SOP~ I.isl. I Gl.09AL FILTER /


Material: FG14, Plant: 1010

PrOC.$Wc ISSUM (6) C<Wrma.ion 1~(2)

Req...ement

10000687
000010 (0001)
Wit~

FG1'
Pt.ant

1010
"''°"""'"
"''""'
Vin
·-
10100011
...,_.,""
PROMOEVENT..
Ol.04.l019(C.ET)
51PC OPC .. OPC
0 @)
10000686 0 3.04 2019(CET)
000010 (0001)
FG14 1010 Goin 10100005 PFIEM!UMCUST..
10PC 0 @)
10000684
FG14 1010
.........
• 10100008 ALL_OruER c _
Ol.04.2019(CET)
10~ .. 10PC
01.04..2019,..0l 04 2019 01.04..2019 .. 01.04 2019
(CET) (CEl) (CET) \CEl)
0 @)

·-
000010 (0001) lOPC
lOPC .. 10PC 10PC .... 10PC

10000685 08.04.2019(CET) 08.04,..2019.. 08.04 2019 08.04..2019 ..08.04.2019


FG1' 1010 10100001 All_OTHER_C .. (CET) (CEl) (GET) (CEl)
0 @)
000010 (0001) • SPC
5PC .. 5PC 5PC -+ 5PC

10000683 0&.04 2010 (CET) OS.04 2019.. 0$.04 2019 OS.04-1019 _. 0$J)4 2019
(CET) (CEl) (CET) (CEl)
0 @)
000010 (0001)
FGt< l010
"" 10100002 NO$CHEDULE_.
lSPC
1$PC -+ 15PC
15 PC..+ lSPC 15PC -+ 15PC

10000682 09.04 2019(CET) 09J)4..2019.. 09.04 2019 09.04..2019...,09().; 2019


000010 (0001)
FG1' 1010 Low 10100004 CREEDITBLOC••
20PC
(CET) (CEl) (CET) \CEl)
0 @)
20PC .... 20PC 20PC -+ 20PC

Figure 5.15 Unsuccessful Backorder Processing Run

Backorder processing is generally run in batch mode, and businesses expect


that a backorder processing run isn't stopped in case of exceptions. SAP has
introduced the concept of a fallback variant with the SAP S/4HANA 1809
release, so that an alternative backorder processing is run automatically in
case of exceptions.

84
5 Backorder Processing

Previous backorder processing variant GLOBAL_FILTER, as shown in Figure


5.12, has now been copied to a new backorder processing variant GLOBAL_
FILTER3, and a fallback variant FALLBACKVARIANT1 has been added, as shown
in Figure 5.16 O. Note that a new backorder processing segment with a stock
transport order has been added with a LOSE confirmation strategy, as indi-
cated by f). Compare this with a previous backorder processing segment
with a LOSE confirmation strategy, as indicated by 9 .

BOP Variant Definition v Q

GLOBAL_FILTER3 Add to Redistribute v Edit Header


Global Fitter

Document Types: Sales Documents Excepdon Behavior: Stop Failed Material· Plant Combinations Global Segment Name: ALLOTHER_CUSTO...
Ch9cking As: S;iit.s Ordtr (Busintss X.natio: A) Fallback Variant Name: FALLBACKVARIA.NT1 0 R&malrung Items: Redistribute
Fallback Behavior: Trigge1 Faltback for Fated Material·Plant Combinations

8 < t:I W Configure BOP Var;ant v Q.

FALLBACKVARIANTl
v

'h'IN GAIN AU LOSE

LOSE

CREEOITBlOCK_CUSTOMER SOLOTOPARTY of d'le ATPOOCUMENT contains ' 10100004'

STOPlANT1010TOPLANT1020 8 PURCHASINGOA:GANIZA'TlON of the STOCKTRANSPOATA ot an ATPOOCUl\iEHT is equal to-1010' and PuRCHASEMOERTYPE of the
STOCKTRANSPOATA of an ATPOOCU,.1£NT is equal to 'UB"
)

SOP Variant DehnrtlQn v

GLOBAL_FILTER
v
m -.. Copy Si~e
-
" Show Last Runs C1

WIN GAlN Fil l i LOSE I

e
Segment Name Se4ed:ion Critena

CREIEDrTBLOCK..C\JSTOMER SOlOTOPARTY ot the ATPOOC:Ufo.iEHT cOt'llallns '10100004' )

Figure 5.16 Global Filter with a Fall back Variant

Now, if the backorder processing variant GLOBAL_FILTER3 is run, then the


stock, as confirmed in the stock transport order, \Nill be unconfirmed
(released) and will be made available for confirmation to other require-
ments (sales orders) with win, gain, and redistribute confirmation strate-
gies. The result of a new backorder processing run with GLOBAL_FILTER3 is
displayed in Figure 5.17. We can see that the stock quantity of 25 PC pertain-
ing to stock transport order 4500000644 has been released and assigned to

85
5 Backorder Processing

the sales orders \<Vith win and gain confirmation strategies, resulting in a
successful backorder processing run. Note the FALLBACK RUNS tab 0 , indi-
cating that this is a fallback run, and the icons in the Processing column,
which indicate the unsuccessful backorder processing run with GLOBAL_FIL-
TER3 and the successful backorder processing run with the fallout variant f).
The stock transfer loses its confirmation, as indicated in Figure 5.17 G.

Mon tor BOP Run v

BOP Runlbt /
GLOBAL_FILTER3 Show V•!Unt r.a
5Yml'Nlry, Slmul.ikln

lktt NaJMc MROY Started 03..()4 2019, 10:34 Requirtmtlflts: 7 Procioued: 7 RequitemHlts f\ily Confirmed Qn.Tm9: 4~

~ted 03-04 2019, 10:36 Pf'OCfl.Slna: l»Uff.; 0 :-.ot Ptocesstd- 0 R~emtnts ~ Conllnned: 43%

A fl
MATERIAl.·PLAMT COl':FIRMATIOH STRATEGY REClPIENT I FALlBACK RUNS
All (2) Proctssing lssun (1) Coriirmation lssuts (2) ...,.. C\ ~
v ©

.
R1quirtmencs Fully Rtquifomtnts FuOy
vanani Name Started Completed Requirements Log
Con~~nm.

GlOBAL_FILTER3 0304 2019, 0304 2019,


67 .. -+ ., .. "°"'""".,
67• .. Show log
Slmc.A<KiOn 10:34 10:34
6

FAllBACKVAR:IANTl 03.04.2019, 03.04.2019,


0 ., ..
Slm-.Jadon 10.34 10:36
' 71• )i 71 • )I
"'" ShOwlog )

Monicor BOP Run v

BOP Rl.l"I List / fM.L.QA,C:KVAAIAHll /


Material: FG14, Plant: 1010 ,._""""' cc

._ - - ........
~ 1$$\lf'S (0)

""""""'
on
todirmauon IS!M'S (•)

Str:.ttgy
·- """"""""' ....,.,. ()n.Tilne eonftmat>On
,...... __
~ OJ,Q.t.201
Ovef.llt eorfunat>On

, 03<>UOJ.
,,_.,,...
"""'"""'
"'"' Ion"'""
q ©

10000•01
000010(0001)
fGl• 1010 \\In 101000U PAOMOEVENf•.
0304 2019
SJ.""
OPC 7' 51 PC • • 0 @)

·-
0PC 7' 51PC Opt 7' 51PC
OJ.04-2019 7' Ol,()4 201 , Ol<>U01

000010(0001)
""" 1010 10100005 PftfMIUMCUST
10""
OPC 7' lO"C • • 0 @)
,_ OJ.04.2010
OPC 7' 10PC
01.04 201 " 03.()4 201
OPC 1' lOPC
01.04 201 " 03.0.UOl
F<>l• 1010
•""""'"" 10100008 .AU_OTliER._.C.
10"" • OPC "' 10'<: • • • 0 @)

·-·
000010(0001)

.
lOPC -t 10PC 10PC,..10PC
....,,,,.... AU....OT'Het__C
0804 2019

oe.04.m ... oe.<l4.201

09.04 201 ... 09.():U()].
• • 0 @)
000010(0001)
f(i1' 1010

10100001
"" OPC > 4PC
~PC '» 4PC ~PC '» 4PC

10000<83
000010(0001) """ 1010 Fill 10100002 HOSOIEDUl..E_
..
05.04.2019
""
090ol 2019

®·°'
OPC -t OPC
05.04.201 ...

15PC " 0PC


201 ...
05.()t 201 ...
• 15PC -. OPC
09.()1. 201 ...
0 @)
"""'82
000010(0001) """ 1010 !OIOOCW:W CREEDITBLOC
""" • OPC -t Opt
20PC "' OPC
• 20PC ... OPC
0 @]
4SOOOOOM4
1010 1020 STOPW4T1010..
"304-2019
2£PC
~ • ~PC '» OPC
Ol.04 201 " 03.04..:ZOI '»
• 0 @)
000010(0001)
25PC " OPC 2SPC " OPC

Figure 5.17 Successful Backorder Processing Run with Fall back Variant

Settings for the backorder processing variant GLOBAL_ FILTER3 with the fall-
back variant are shown in Figure 5.18. You can see that the fallback variant

86
5 Backorder Processing

FALLBACKVARIANTl is assigned for exception behavior Stop Failed Material-


Plant Combinations. There are two options for Exception Behavior 0 :
• Stop Failed Material-Plant Combinations
• Stop Completely

There are also two options for Fall back Behavior f):

• Trigger Fall back for Failed Material-Plant Combinations


• Trigger Fallback Without Restrictions

Variant Settings

* Variant Name: GLOBAL_FILTER3


l
Variant Description: Global Filter 3
l
Execution Options

* Document Types: Sates Documents Stock Transport Orders J

* Checking As: Sales Order (Business Scenario: A) cJl l


Configuration Options

0 Exception Behavior: Stop Failed Material·Plant Combinations v

Fallback Variant Name: FALLBACKVARIANTl OJ I ® I


f) Fallback Behavior: Trigger Fallback lor Fail ed Material·Plant Combinations v

Global Segment Name: All_OTHER_CUSTOMER OJ I ® I


Remaining Items: Redistribute v

Figure 5.18 Settings for Backorder Processing Variant w ith Fall back Variant

The following process for fallback behavior with exception behavior is


shown in Figure 5.19:

0 A backorder processing variant is selected for execution.


f) Processing for backorder processing is started and checked for excep-
tions (i.e., sales orders or stock transport orders with win get confirmed
or not and with gain can retain their confirmations or not).

87
5 Backorder Processing

9 In case of no exceptions, requirements (sales orders or stock transport


orders) get updated as per the strategies set in the backorder processing
variant.
0 In case of exceptions, the system checks whether backorder processing
will be stopped completely or not.
0 If backorder processing will not be stopped completely, then the require-
ments that do not have any exceptions for the respective material-plant
combinations are marked for update. (For example, if backorder process-
ing is executed for two materials A and B for plant 1010 and if there is an
exception for only material A for plant 1010, the requirements for mate-
rial B with plant 1010 are marked for update.)

0 No
Update
Execute BOP requ irem ent s
va riant (ma in,
unrestricted,
and restricted)
~ o
Yes

Complete No
,....---·
Mark requirements f or
all exception -free material-
>---l~I plant comb inat ion s
stop ?
for update
Yes

Figure 5.19 Process for Fall back Variant with Exception Behavior

0 If the backorder processing will be stopped completely, then the system


checks whether there is any fallback variant.

88
5 Backorder Processing

f) If there is no fallback variant, then the system checks whether there are
any requirements that have been marked for update, and if so, then they
are updated, as explained in step e.
0 If there is a fallback variant, then the fallback variant can be restricted
through a global filter for exceptions with failed material-plant combina-
t ions.

Note
GLOBAL_FILTER3, as shown in Figure 5.18, has a restricted fal l back variant.

0 The fallback variant can also be unrestricted (i.e., the selection is indepen-
dent from the previous steps and not run for failed material-plant com-
binations). Settings for the unrestricted fall back are shown in Figure 5.20.

Variant Settings

General Information

*Variant Name: GlOBAL_FILTER4

variant OMCJiptJon: Global Fetter 4 unieSll1ded

Execution Options

• 0oa.iment Types: Sales Doo.ments Stock Transport Orders l


•Chedci~ As: Saltl'S Order (Business Scenario: A) 61

Configuration Options

Exception BehaiAor: Stop Failed Material-Plant Combinations v

Fallbact Vari.ant Name: FALLBACKVARIANT2 g l


I Fallba<:k eehMor Triggei Fatlb.lck VAtholt Restrictions

Global ~t N•mo: All._OTHER_CUSTOIAER

A:emaining Items.: Re<llSlribute v

8 <0 & BOP Variant Definition v

GLOBAL_FI LTER4 Add to Redistribute ...,. I Edit Heade


Gl.obat Hter 4 l.h'~strict!d

OoC\.ment T)pes: Sates Documents Exception 8eh31Aor: Stop Failed Material-Plant Com~bons GloOOI. ~Name: AlL._OTMER_CUSTO...
Cheddng As; sates Ofder (Bu!iness scenario: A) F.Uback Vari•.. Name: FAUBACKVAAIANT2 R...-ng """' Re<lslrtbute
l Fallback ll<!l<Mor· Tngger F•llback v.tthout ReSlrictions l
A p

Figure 5.20 Global Filter with Unrestricted Fall back Behavior

89
5 Backorder Processing

Not e
A fal l back variant can also have another fallback variant. There is no technical
restrict ion on the number of fa ll back variants; however, it is recommended to
restri ct the number of fall back variants from the perspective of complexity and
performance.

5.6 Combining Backorder Processing with


Product Allocation
Businesses expect that backorder processing will consider the product allo-
cation quantity for the respective material (i.e., the confirmed quantity
should not be more than the allocated quantity). Backorder processing
works with product allocation in aATP in the SAP S/4HANA 1809 release, as
shown in Figure 5.21.

Material FG14 has been allocated with 7 EA for the customer 10100005 for
the week starting on April 8th. Order quantity for the sales order 10000686
is 10 EA and is unconfirmed. After backorder processing run, this sales order
10000686 with gain confirmation strategy has been confirmed with 7 EA
(i.e., not 10 EA), as expected due to product allocation set for only 7 EA for
the week starting on April 8th.

Not e
SAP has released SAP Note 2563508 for product allocation to support w in, gain,
fill, and lose backorder processing confirmation strategies in the 1709 release of
aATP.

Not e
Backorder processing does not work with ABC as of the 1809 release of SAP
S/4HANA. The 1905 release of SAP S/4HANA Cloud and 1909 release of SAP
S/4HANA on-premise are ant icipat ed t o include backorder processing and con-
sider ABC f unctionality.

90
6 What Is Release for Delivery?

Product Allocation Object v

PAL 4 PAL' Sates Ora Sold lO PirtY Mitenal


Period Typt: Ylffk (02) CrNttd By:

PeriOd Tme Zone. VTC•O(VTC) CteatiOO Oete nnt>. 28.11..2017, 14.22:05


Owncxy Un«: each (EA) Last c~nceo ey:
Col!Ktiw: Colt.ctiw Allocation Man.itg.d Manua.t!y (02) Last Chang• Dato limo: 09.04..2019. 06:52:23

Srieetion RM1gt>:
20.0J.20 1,. 24.06.201, rn
Product AUocation Planning Data (4) ...,.. 0. Switeh to Oe-scrip(!On Vtew ShowCo~on .!.
n

-·......
S.les Otga~atlon SoW·To Party· CUSt... M«e~l Ni.mbff Status Const.ralnt Stailus 18.03 2019 2S.03 2019 01.04 2019 0804 2019 15.04.2019 23.04.201~

0 1010 10100001 fGoe


""""'"'
Av.ail•bllty
RMtl'kted
10 0 0 0 0 0

-·-·
0 1010 10100001 FG12
A.v•ibblity
100 100 100 100 0 0
Rt$trkted
0 1010 10100001 FG216
Avallabllty 0 50 50 50 50 0
RMtricted
0 101~ FGl.4 8
1010
AvallabUty
0 0 0
' 0

t..1onitor BOP Run v Q

BOP Run Use I BOPGAI NLOSE I


Material: FG14. Plant: 1010

Roquirornents 2 ProcrAed: 2 RoquS~oru Fully Conflrmod On-limo: 0%


PrOC.!-1oil"C lsSUH. o Not Pftl<essed: o R~~e-nu Fully conr•tne<I. O'lti

A!I (2) 0. ©

R9qu1rorrent Material
"""'
Con"""'
Ion
Slrattty
Reclpitnt S.~tntN~me ........ On.Tim• Confirmation Ea.rtiest ConlWmatlon Overalt onfim»tlon
Processin
I Sla1US
Confirm

......
~ion

09.04.2019 ~ 09.04 20 ~ 09.04.20


1000068< 1010000
000010 (0001)
FG14 10 10
""" 5
CUSTOMER_..•
IOP<:
OPC l4 1PC
0PC )l 7PC
19
0PC )l 7PC
19
0 @)
10000682
000010 (0001)
FG14 10 10 ,... 1010000
4
CUSTOMER_..•
09.04.2019
20P<:
OP<: ~ OPC
09.04 20
19
'\II 09.04 20
19
'\II

0 @)
20PC 'lll 0PC 20PC 'lll 0PC

Figure 5.21 Successful Backorder Processing with Product Allocation

6 Release for Delivery


Release for delivery is a new functionality in aATP (i.e., it does not exist in
ERP ATP or GATP in SAP APO). It is a process prior to delivery creation and
provides the option to manipulate the order confirmations for last-minute
changes (i.e., even after backorder processing). Sales orders or stock transfer
orders are subsequently prepared for the next logistic process step: creation
of delivery.

91
6 Release for Delivery

The Release for Delivery app provides the following features:

• Workload based on area of responsibility (material, plant, etc.).


• Available (but unused} stock displayed graphically with its assignment to
requirements (sales order items).
• If backorder processing can't confirm all sales orders or there's a deficit in
confirmation, confirmed quantities can be changed (interactively) be-
tween sales orders or stock transport orders. For example, if there is a
rush sales order for a material with a required quantity of 2 pieces and
there is another sales order with a confirmed quantity of120 pieces, then
the rush sales order for 2 pieces can be confirmed by reducing the confir-
mation of the other sales order to 118 pieces.
• Direct navigation to sales or stock transport order.
Let's walk through the relevant SAP Fiori applications before we see how
release for delivery works with product allocation and alternative-based
confirmation (ABC).

6.1 SAP Fiori Applications

There are three SAP Fiori apps that include release for delivery functionality:

• Configure Order Fulfillment Responsibilities


• Release for Delivery
• Schedule Deletion of ATP Results Log

Note
Like the prerequisite settings for the product allocation and backorder process-
ing SAP Fiori apps listed in Table 3.3 and Table 5.2, the settings in Table 6.1 need
to be set for the Release for Delivery SAP Fiori apps to be displayed in t he SAP
Fiori launchpad.

92
6 Release for Delivery

SAP Fiori App Activation of Activation of Assignment of


ICF Nodes: OData Services: User Role:
Transaction SICF Transaction Transaction
/N/IWFND/ PFCG, SU02
MAINT SERVICE
Configure order /sap/be/ ATP SAP- BR- ORDER
fu lfillment responsi- uiS_uiS/sap/ RESPONSIBILITY FULFILLMNT
bilities atp_configofrsl CON FIG MNGR
Release for delivery /sap/be/ ATP- RELEASE SAP- BR- ORDER
ui5_ui5/sap/ FOR- DELIVERY FULFILLMNT
atp_rel4delivsl SPC LST
Schedule deletion of /sap/bc/uiS_uiS/ APJ - JOB SAP- BR- ORDER
ATP results log sap/nw_aps_apj MANAGEMENT- SRV FULFI LLMNT
MNGR
Table 6.1 Prerequisite Settings for SAP Fiori Apps to Be Displayed

We'll discuss each of these apps in the following subsections.

Configure Order Fulfillment Responsibilities


This app supports scoping the order fulfillment responsibilities for a busi-
ness user based on specific parameters (material, plant, etc.) within a spe-
cific time period, as depicted in Figure 6.1. The general information and user
assignment can be edited, deleted, and shared by mail O. In the Business
Task Specifics tab 8 , you can see whether the release for delivery includes
sales orders and/or stock transport orders. In the User Assignments tab, you
can also see the validity range with the date, time, and time zone 8 .

93
6 Release for Delivery

8 < ~ & Order Fulfillment Responsibility v

GERMANYPLANT1010

General Information
Order resp for materials in Germany plant 1010

Business Task Specifics User Asslgnmems


Tm Delete
~1

General Information

General Information r Business Task Specific;·-j User Assignmems


Responsibility Name:
GERMANYPLANT1010
'- 8
Resp. Description· Release for Delivery
Order resp for materials in Germany plant 101
Include Sales Orders:
Responsibility Definition:
Yes
Plant of the ATP Material is equal to '1010'
Include STO:
Default Horizon:
Yes
180

General Information Business Task Specifics ______ ,_,_,,_,,_,_,,_,_!


User Assignments .._,1

Assigned User ' Validity End Validity Start Validity End Time Zone Validity Start Time Zone

MROY 31.12.2019, 23:59:59 01.03.2019, 00:00:00 CET CET

Figure 6.1 Configure Order Fulfillment Responsibility App

The SAP S/4HANA 1809 release provides parameters for the Responsibility
Definition field, as follows:

• Plant • Material type


• Plant region • Product hierarchy
• Sales organization • Packaging material group
• Distribution channel • Material group
• Division • Intercom pany billing division
• Material

94
6 Release for Delivery

This app also allows you to do the following:

• Create multiple order fulfillment responsibilities in one step (with the


Mass Create option), with the split parameters (previously listed) with
specific validity ranges and user assignments.
• Edit existing order fulfillment responsibilities, validity ranges, and assign-
ments (Figure 6.2).

Configure Order FuUillment Responsibilities v

Standard v

Eciti"S" StA!itus: Responsi>ilty NillmO: Art. As.sif:ned Usen.:


v 6' Acl.flpl Rt.ers ( 1) m
Order Fulfillment Responsibilities (1) + ©

0 GEAMANVPl,.ANT1010 Ord•r r• sp f0t m.>,teriats in Gorm.any plant 1010 PLANT of tho ATPMATERIAL b oqual to ' 1010' 180 DAY 1

Figure 6.2 Configure Order Fulfillment Responsibility App

Release for Delivery


There are a few prerequisites to use the Release for Delivery app, as follows:

• aATP must be activated for the material (see the Availability Check Group
section).
• At least one order fulfillment responsibility must be assigned to the busi-
ness user in the Order Fulfillment Responsibilities app.
This app lists three process statuses, as shown in Figure 6.3:

• Unpre pared
This is the entry screen for the Release for Delivery app, as shown in Fig-
ure 6.3. It displays the materials, which have at least one sales order or
stock transport order with no "full confirmation" and the corresponding
quantity already confirmed 0 , the quantity available for further confir-
mation e. and financial impact e.

95
6 Release for Delivery

If a particular material is selected, then Release for Delivery, as outlined in


a box in Figure 6.3, gets highlighted, and if you click it, then the corre-
sponding sales orders or stock transport orders for the selected material
are released for further logistic processing, like picking and so on.

Note
The length of the Impact bar indicates the potential financial impact of being
unable to confirm all sa les o rd er items of a material. The value of the impact is
determined by multiplying the net price of each sales ord er it em by the uncon-
firmed quantity. The determ ined value of impact is then converted to a sca led
va lue between zero and 100, so t hat sensitive pricing information isn't exposed.

Release for Delivery v Q

GERMANYPLANT1010 G

Hori?on: 4320 h

o· >» ®' »> ®'


Search for a speciRc material •I

Material Plant lmpac[ Confirmation Availabithy

FIN126,MTS·Dl,PO,No Serial TM POSC 1010 . 2541393 PC


D FG 12 Plant 1 DE \'lalldorf
9
A ·139 PC
139 PC+ 72

AATP BOP Test 1010 . 751136 PC


D Plant 1 DE \'lalldorf 2
A 61 PC
OPC >
FG15 0

AATP Test material 06 1010 . 56162 PC


D FG06 Plant 1 DE V/allclorf • 2
A ·6 PC
OPC

Figure 6.3 Unprepared Screen for Release for Delivery App

If you click on the material, such as FG06 in Figure 6.3, then you get sales
orders with the material FG06 with the corresponding confirmation and
availability situations, as shown in Figure 6.4. It shows that the sales order
10000669 is fully confirmed with required quantity of 45 PC. However, an
important customer 10100002 needs 2 PC of the same material FG06 very
urgently, but the correspond ing sales order 10000667 isn't confirmed.

96
6 Release for Delivery

The Release for Delivery app provides the option to change the confirmed
quantity after backorder processing.

Note
Dependency is a new feature introduced in the 1809 release of SAP S/4HANA, as
shown in Figure 6.4. If the order has a delivery group set as, for instance, sales
order 10000657 (i.e., the ordered quantities for the materials FG06 and FG07
need to be delivered together), then it will be marked for dependency and its
order quantity can't be changed.

Retease for Delivery v

AATP Test material 06

M.uor\.11; FG06
Plant. 1010 • Plarw l OE Walldolf 0 •
HOrilon: 4320 h
• Co1'4imwd • Avaitabte • 0-..conl'irmed • Unccnfirm~

rte~ (4) 0. c t; ©
SalHOrder Sat.es doci.neM type OocutneM Oa1e S"'""ng D.Me-s Co~itmaL<ln
E:]ol 6l Del)ffldtncles

lhlJ. 2803
v~6\
lnlandtltund• OE 4
0010000671
_,, OR • Su,nd.3rd Order 2403 2019 27.03.2019 Fri, 29.03. 7 •
1010IXI04 R Sit. J0.00.
- oc

0010000669
Inland·
lohnMarb.iter A ,
OE
10100007
2403 2019 27.03 2019
Thu. 28.0J.
f". 2903.
"it' Sit. 30.03
•• - oc
..
,
" o[!J
lnl.,.ndslcund e DE 2 Thu, 28.0J.
0010000667 2403.2019 lo · ~oc O l 6\
10100002
27.03 2019
~
f " , 29.0J.
Sat..30.03 "
0010000657 lni.ndUund• DC 1
27.03 2019
Thu. 2803
frl, 29.<>3. 4
_,. ., o J6\ ~
10100001
'Jitl ~"· 31.0l. "°

0010000657 000010 1010

00100006~7 000020 FG07 1010

Figure 6.4 Unprepared Sales Orders for a Particu lar Material

Now the Release for Delivery app allows the confirmed quantity to be
reduced from 45 PC to 43 PC for sales order 10000669 (as it has no depen-
dency, as explained previously), and the same quantity (2 PC) can be
assigned to sales order 10000667, as displayed in Figure 6.5.

97
6 Release for Delivery

Release for Delivery v c..


AATP Test material 06

MatoriM: FGOS
P~nc: 1010 . Plan! 1 DE WaUdorf
Horizon; 4320 h
• Conllmwd • Av•ble
..
• Over-confirmed •
0

Uncontlfmable

llems (4) POS(l)Otlt'O Items (0)

Rf'Q. Mat. Al/ail.


S.s0ttl•1 Sold.To P•rty Sales docl.#ntnt type Docum"1t Date Shipping Oltes CoNIM'18tlOn
"Io @
"'"""""''°'
lnl•11dskurKle DE 4
"" TOO, 28.03.
0010000671
~ 10 100004
OR • St.andatd Order 24.03.2019 27.03 2019
'l;\"
Ftl. 29..03.
Sat. 30.03.
I1 :~
" O J@
Inland•
lohnbf.•r'Mker A , ...... 2$ 03
0010000669 OR • S~ncl•td Orditr 24.03.2019 27.03 2019 Ftl. 29.03. .i. 143 :~ O J@
DE
10100007
'11':" Sat, 30.03. "
lnlandt.kuAd• OE 2 Thu, 28.03
0010000667 1' - 1-PC O J@
10100002
OR • Standard Order 24.03.2019 27.03 201'3 Fri. 29.03.
"P.:" SM. 30.03
2
-
"
00100006.57 lnlands.k urKle DE 1
10100001
OR • Standard Order 21.03.2019 27.03 2019
~
Thu, 28.03
Ffl. 29.03.
Sutl. 31~03.
4 - ,."' " O J@ a;

Pl.1bll.sl"I and Nort v s....,..,

Figure 6.5 Change of Order Confirmation in Release for Delivery App

Sales orders are subsequently published and appear in the next status
(prepared) of the Release for Delivery app.
• Prepared
This is the next status or screen of the Release for Delivery app. It displays
the materials for which the sales orders or stock transport orders are fully
confirmed, or the material that has been published from the unprepared
status, as shown in Figure 6.6. You can see the material FG06 (as described
in the previous step) and materials FG201 and FG07, which do not have
any issues with confirmation.
Materials FG06 and FG07 are then selected, and then the release for deliv-
ery is clicked to start the further logistic processes for the sales orders and
stock transport orders for these materials, which now appear with pro-
cess status Released.
• Released
This is the final process status in the Release for Delivery app, as shown in
Figure 6.7. As expected, you can see the materials FG06 and FG07 (de-
scribed previously) marked as released. Corresponding materials can now
be selected and set for Released for Delivery for creation of delivery.

98
6 Release for Delivery

Release for Delivery v a.


GERMANYPLANT1010 G

Hoitzon: 4320 h

®' ) )
~
m·) ) ®'
P. . .e<ll AN°"*'

SHrth '°' ii -speo·fk mllf tNi81 ~ c • •• Dt ~~y

0 M•ttri.. ..... lmp•ct a.dtordertd ltitms Codirmation Availability

AATP Te st material OC 1010. 56162 PC


0 Pl.int l DE \'l•lldotf • 2 A-6 P<
0 l'C >
FG06
Sf No ' erlal no batch 1010.
0 Pl.ant 1 0£ \'/alldorl 0 lOllO EA O EA >
FG201
AATPTest 1010.
0 FG07 Pl.ant l DE \ 1/aolldorf 0 313 1'< 0 PC )

Figure 6.6 Materials with Prepared Status for Release for Delivery

Release for Detiveiy v

GERMANYPLANT10 10 G

Horizon: 4320 h
A

@' ))) @' ))) • .

~ c Rele ~e- fl" DI •


'
0 Matefl•I 8ac:kordt<ed Items Confirmation Av-

0
SF No seri•I no batc h Segmentatlon
FG251
1010.
P\ant 1 OE Waltdoff
- 1
1~16S !A
6 ·15 EA
-150 tA )

0
fl:N U6, Multi mode
fGlOO
AATP T-.1 matffi•l Of>
1010 .
P\ant 1 OE Ylalldorl - 9
0.112 P(
A·U PC
12 PC >

1010. 5&'62 PC
0 FG06 Plant l OE Walk:Soff • 2 . . . l'C
OPC )

AATP TiHt 1010 .


0 Plant l DE Walkkwt
0 313 P< OP< >
fG07

Figure 6.7 Release Status of Release for Delivery

Before we move on to discuss the next SAP Fiori app, note that there is a lim-
itation of the Release for Delivery app in the SAP S/4HANA 1809 release.
The Release for Delivery app creates a work list (as a snapshot) with open
sales orders (or stock transport orders) due for delivery. (This behavior is
similar to m ass delivery creation with VLlO*.) If certain sales orders (or stock
transport orders) are created, changed, or deleted, then they are expected to

99
6 Release for Delivery

be reflected in next run of release for delivery. However, that does not hap-
pen as of the 1809 release of SAP S/4HANA. You might see that release for
delivery isn't showing the correct data/sales orders (some sales orders or
stock transport orders aren't being displayed or some deleted orders are
appearing), even though the relevant material, plant, and so on have been
defined in the Order Fulfillment Responsibilities app.

SAP may provide a refresh option in a later release. For now, the following
workaround may be used to create a new work list in aATP for the Release
for Delivery app:

1. Open the Configure Order Fulfillment Responsibilities app and navigate to


the details of the responsibility name for which the work list needs to be
reset.
2. Click Ed it.
3. Delete the assignment of the responsibility to the work list processor.
4. Click Save. The work list has no\.v been reset.
5. Click Edit again.
6. Reassign the responsibility to the work list processor.
7. Click Save.

Note
The functionality to refresh the order items for release for delivery is expected
in the 1909 release of SAP S/4HANA. This refresh functionality is planned to be
included in the 1905 release of SAP S/4HANA Cloud.

Schedule Deletion of ATP Results Log


With this app, jobs can be created and scheduled to delete the following
items:

• ATP results log displayed in the Release for Delivery app


• Backorder processing results displayed in the Schedule Backorder Pro-
cessing Run and Monitor Backorder Processing Run apps

100
6 Release for Delivery

The system deletes the log based on the number of days mentioned in the
field Older than (Days), as shown in Figure 6.8.

8 < ~ w New Job v ATP Runtime Object Management

Schedule Deletion
of ATP Results Log
ATP: Backorder Processing Result Deletion Default

GENERAL INFORMATION SCHEOUUNG OPTIONS PARAMETIORS

*Job Template: ATP: B&ekorder Prc>«Ming Result D&letie Ql

Job Name: ATP: Backorder Processing Result Deletion ...


Scheduling Information

Scheduling Options Start lmmediatety: 0


Job S<art: 09.05.2019. 16:27 Central Europe

Re<urrencePattern: ~Io_. ;_1y _ _ _ _ _ _ _ _ _ _~


v I
Start Immediately: 0
Evt<y: 1 O•y(s)
Start: 09.05 2019. u;·21
End: I None v

Parameter Section
OnNon-We>tkingOay: ~[N_o _r.._u_ieti_on_ _ _ _ _ _ _ _~
vJ

Backorder Processing Run Calendar: Germany (Standard) v

• otder than (Days): 30

UHJName:
l2EJ Re~et Schedulll'lg Option~ Cancel

Figure 6.8 Schedu le Delet ion of ATP Results Log App

6.2 Combining Release for Delivery with


Product Allocation
Release for delivery checks for the product allocation of the corresponding
material-plant combination, and the quantities in sales orders or stock
transport orders can't be changed, to avoid a situation where the quantity
confirmed at release for delivery is more than the product allocation quan-
tity. The system displays a message This requirement is impacted by product
allocation and cannot be processed, as shown in Figure 6.9.

101
6 Release for Delivery

Release tor Oetivery v

SF No serial no batch AATP PAL ABC

Maten.al fG216
P\.ant; 1010. Aant 1 OE v1.i1dorl 25 00
Horizon 4320 h • Confirmed e Avallabte • OYKconf.flMd • Uncontlrmable

-·.....
ttc m$ (1) P<*ponod ttoms (0)

S.i.s Ord•r Sold-To P.arty Sal•• dow1Mn1 cype Oocum~ 0.att


Req. M•t. Avail.
S~O•tts Contlrm<ltion viol @ (';

0010000673 tnland$kunde DE 1
"" Th.I. 2$.03. , ..
OR · Su1ndard Ordef 25,03.2019 27.03 2019 Fri, 2903 2' .... 0 I? ,
10100001 "i" Sal:, 30.03
"'

Figure 6.9 Release for Delivery in Combina tion with Product Allocation

6.3 Combining Release for Delivery with


Alternative-Based Confirmation
Release for delivery also checks whether there is any substitution of loca-
tion following ABC, as discussed in Section 4. Figure 6.10 shows the message
that the sales order 10000674 is impacted by substitution (the location is
substituted) and its quantity can't be changed O. It also shows that the
quantity in the sales order 10000674 has been confirmed, as per the product
allocation quantity set for the week beginning March 25th f).

. <
ABCPLUSPAL .i.ec...,.PiU.

,._,. T~ .,.,....,!01) ~ &y

........,,.._,_. e..-it._tcfl) o.-o...n- 20et!'Ol,~2J

°"""«1U.. NdlllAJ l.H:O......,.,.


~ ,..~-~{01) ...~0-.,..0Motf- l)Ol-:Z01t..U.,l~
P1¥t lOU P<or-f 2 OF -~
Or1[)rctl P<vr 1010 ,,_., I !'If W-

" ..
,Yf

p~ ~~SD.tl•(I)

- ---
• ()io.llfntdtl <nr.,;i dOI <IO
$C!Wol9P"'1)'•t'\llC. ~,._,..._

Of¥tor10lt" 300S101t
0

II <
SF No serial no batch AATP ABC

.....-~1!1
,. "
.....,...,,
__
"-"' 10U-~lot"""""'

..,

0010CO:lll4

"""''
l~OE I Olt·~·°"'"'
--
2$.Q.120l'

I <> ,...._.~....,.,,~
r... ~-~ ~• ...... ..

Figure 6.10 Release for Delivery in Combination w ith ABC

102
7 What's Ahead for aATP?

7 What's Ahead for aATP?


Since its introduction in SAP S/4HANA 1610, aATP has been enhanced sub-
stantially in the 1709 and 1809 releases and will continue to be enhanced
further in the next few releases. SAP has plans for the enhancements listed
in Table 7.1, as per the SAP roadmap for aATP in upcoming releases.

2019 2020 2021 and Beyond


Planned Innovations Product Direction Product Vision
Product allocation: Product ava ilability check: • ATP ana lytics
• Consider multiple prod- • Product availability • Fair share logic in back-
uct allocation objects check explanation tool order processing
and final confirmation • Integration w ith trans-
ABC:
of m inimum using logi- portation management
cal constraint AND • Material substitution
(selection of best alter- • Multilevel ATP (MATP)
Backorder processing: native material) • Capability-to-promise
• Custom fields for sort- (CTP)
Backorder processing:
ing and filtering • Int eractive backorder
• Enable users to analyze
ABC: processing-manual
the constraining fac-
and fast adj ustment of
• Enable partial confirma- tors of an ATP check in
the confirmation of
tions in multiple plants the backorder process-
mu ltiple order lines
• More intelligence and ing monitor
within an integrated UI
building rule in determ i- • Flexible aggregat ion of
• Machine learning capa-
nation of alternative mass data in backorder
bilities
plants processing monitor
• ABC to work in combi-
nation with backorder
.
processing

Release for delivery:


• Refresh ofworklist

Table 7.1 Roadmap for aATP

103
7 What's Ahead for aATP?

Note
SAP has set the roadmap in Table 7.1 for aATP in Q2 of 2019, but the enhance-
ments in actual releases may be d ifferent due to various reasons. See https://
www.sap.com/sweden/product s/roadmaps.html fo r the latest roadmap up-
dat es.

Also refer to Note 2642047 for the restrictions of aATP in the 1809 release of SAP
S/4HANA.

Some of the most important and expected enhancements are as follows:

• Product substit ution


If a specific material isn't available, it can be substituted by a material
with an equivalent or higher specification. For example, say an automo-
bile manufacturer of a specific model has a tire of a particular make,
"ABC", in its BOM. Ifthe tire of make ABC is not available, then a tire of the
same specification of another make, "XYZ", can be used as a substitute.
The material substitution will have a similar framewo rk of ABC, as intro-
duced for location substitution in the 1809 release of SAP S/4HANA.
• Profitability-based ATP
Markets today are very competitive, resulting in thinner margins (profit).
In case of constrained supply (or demand exceeding supply), most sellers
are aiming for order promising to max imize profit. If an order from a cus-
tomer with a higher price is expected in the near future (say, in a few
days), then the seller may decide to keep the stock for that customer
instead of selling it to another customer with a lower price (and thus
reduced profit). A history of orders (demand) and analytics are important
considerations for profitability-based ATP.
• Integration with SAP Transportation Management
aATP determines the material availability date. However, customers are
interested in the delivery date, as well- that is, the date on which material
will be delivered to their warehouse/site.
SAP Transportation Management (SAP TM) is embedded in SAP S/4HANA
1709. SAP TM lets you schedule sales orders with advanced transportation

104
7 What's Ahead for aATP?

planning functionality. Sales order scheduling will be simplified (and made


more robust) if the determination of the material availability date in aATP
is integrated with the determination of the optimum transportation time
to arrive at the delivery date at the destination location of the customer.

Note
GATP ca n't integrate direct ly with SAP TM, so two separate calls (one to SAP
APO and another to SAP TM) are needed to derive t he delivery date (which is a
maj or limit ation f or customers using bot h GATP and SAP TM). However, now
the integration of aATP (the successor of GATP) w ith SAP TM is feasible with t he
merger of GATP and SAP TM in the SAP S/4HANA core.

• Integration with SAP Integrated Business Planning


SAP recommends (in SAP Note 2456834) migration to SAP Integrated
Business Planning (SAP IBP) for customers using the SAP APO DP and SNP
modules. SAP IBP has five modules, as depicted in Figure 7.1, and the
response and supply module also has capabilities for product allocation
and order promising. Thus many customers using SAP IBP for response
and supply will look for its integration "vith aATP for order promising.
There is no fully automated integration between SAP IBP and SAP
S/4HANA as of the 1809 release of SAP S/4HANA, but SAP is working
toward it in upcoming releases. However, there are several application
programming interfaces (APis) available in the current release to link
product allocation fro m SAP IBP with aATP in SAP S/4HANA.

Supply chain Sales and operational Response


Inventory Demand
control tower planning and Supply
SAP Integrated Business Planning (SAP IBP)

I aATP
I
SAP S/4HANA

Figure 7.1 Integration of SAP IBP for Response and Supply with aATP in SAP S/4HANA

105
8 Migration at a Glance

Note
SAP IBP is a separate SAP application available only in the cloud.

8 Migration at a Glance
SAP has declared that aATP will be the successor of SAP APO GATP. How-
ever, aATP is still evolving, and it will take several years to develop all the
future functionalities for aATP as planned by SAP as in their roadmap (dis-
cussed in Section 7).

Note
There will be no migration tool to migrate from GATP in SAP APO to aATP, as the
design principles in aATP are different from GATP in SAP APO.

The migration to aATP will not be unique for all customers; it will depend
on the extent of the use of ATP in SAP ERP and GATP in SAP APO. Figure 8.1
shows the different migration scenarios for different sets of customers:

0 New customer
A new customer using SAP S/4HANA can use aATP from the very begin-
ning. In fact, there is no migration in this case, excepting master data.

Note
Present SAP ERP customers implementing SAP S/4HANA as a greenfield option
w ill also fa ll into this category of new customer.

f) Existing SAP ERP customer migrating to SAP S/4HANA


This customer an fully migrate to aATP to enjoy faster performance, eas-
ier setup with SAP Fiori apps, and so on.

106
8 Migration at a Glance

0 SAP S/4HANA aATP from the beginning f) SAP ERP ATP to


SAP S/4HANA aATP (Full)

I aATP I I ATP I I aATP


SAPS/4HANA SAP ERP SAP S/4HANA

New customer Existing SAP ERP customer migrating to SAP S/4HANA

SAP ERP ATP to


SAP S/4HANA aATP (Part)
0 SAP ERP ATP and SAP APO GATP to
SAP S/4HANA aATP (Full)
~---~

I []f[]
ATP
~ ~ - - IGATP I I aATP I
SAP ERP SAPS/4HANA SAP ERP SAP APO SAPS/4HANA

Existing SAP ERP and SAP APO CATP customer


Existing SAP ERP customer migrating to SAP S/4HANA
migrating to SAP S/4HANA (Full)

SAP ERP ATP and SAP APO GATP to SAP S/4HANA aATP and SAP APO GATP

~
SAP ERP
IGATP I
SAP APO
~ p
SAP S/4HANA
IGATP I
SAP APO

Existing SAP ERP and SAP APO CATP customer migrating to SAP S/4HANA and SAP APO CATP

Figure 8.1 Migration Scenarios fo r aATP

As discussed earlier and shown in Figure 8.2, activation of aATP is done at


the availability check group, and the value for availability check group as
set in the material master controls whether classic ATP or new aATP will
be called. Note that the value of availability check group is in plant view
of the material master; hence the call for ATP or aATP is fixed for a partic-
ular material-plant combination.
As discussed in Table 1.2, all existing settings of a classic ATP check in SAP
ERP are also used in aATP. The main difference is ifthe availability check
group is activated for aATP or not. If activated, then aATP is called (with
new algorithm) instead of ATP.
If the customer uses product allocation and backorder processing, then
all the relevant settings need to be created through SAP Fiori apps, as dis-
cussed in Section 3 and Section 5, respectively.

107
8 Migration at a Glance

Note
Location substitution functiona lity with ABC works only at the creation of a
sa les order in the 1809 release of SAP S/4HANA. As a result, SAP does not recom -
mend using ABC in the production environment of the SAP S/4HANA 1809
release. Th is limitati on is expected to be eliminated in the 1909 re lease of SAP
S/4HANA on-premise.

Chilnge View "Avilifilbility Check Control": Overview


~ New Entries CD ~ ti:) ~ ~ (]
--
Av Descrtitlon TotalSales TotOlvReqs Block QtRQ No check Acct.m ••. Re«:hkPlan Advanced ATP
r illc No PAC Check 0 0 •
H sp Stock and Plan. Re. A A 0 0 3 •
SR Stock and Rel. Rec. A A 0 0 3 •
H sr Consider Qiy StockA A 0 0 A Accive • ,
r.
Yl Indvid.requiremen_.A A r1 3 ~ A.ccive •
Y2 !nd.ReQ.ctn;J.Che_ A A " 0 3
~
A Act.ive •"
Y3 Only ATP no PAL A A 0 0 3 A Acti ve •
H

[~ 1,1 Change Milter/a/ FGJ.1. (Finished Pro duct)


:0 ¢ Adcitional Dat a f.o C:Xg. Levels iiiC Check Screen Data n
Cl

/ Sales: sales erg. 2 -r.> Sales: General/Plant I' Forelgi tracle emort v Sales text 'I EJl!]!Ci

Material
Descr.
lrGll
fG AATP Test 11'
I
-~
um ~

Plant 11010 Plant l OE

Gene1al data
Base Urlt of Measure ST Piece Replacement Part D
Gross wei(tlt 0,500 JlKG1 Qual. f.FreeGoodsOis. 0
Net weight lo,4so J Material freQ"lt grp I I
Avallablty check rvl1 Indivtd.requi"ements
A~.batch rec. req. 0
Batch manaoement 0

Figure 8.2 Availability Check Group Controls the Call for ATP or aATP

Note
SAP S/4HANA does not support summarized requirements; it only supports
individual requirements. Report ATP_TRANSITION_S4_ VBBS should be used to
transition summarized requirements to individua l requirements, as recom-
mended in OSS Notes 2209696 and 2267745.

108
8 Migration at a Glance

9 Existing SAP ERP customer migrat ing to SAP S/4HANA


This customer can partly migrate to aATP (i.e., they can continue using
ATP of SAP ERP for certain material-plant combinations).

Note
Classic ATP and aATP can be run simultaneously, depending on the setup of the
checking group in the same SAP S/4HANA system. If the checking group is acti-
vated for aATP, then aATP is ca lled for the materials with that availability check-
ing group.
However, product allocation in aATP and in SD (as in classic SAP ERP} can't be
executed simultaneously in the same SAP S/4HANA system. If product alloca-
tion is activated in aATP in SAP S/4HANA, then it can't be rolled back to previ-
ously used product allocation functions in SD.

0 Existing SAP ERP customer with SAP APO GATP migrating to


SAPS/4HANA
This customer can migrate to aATP without GATP in SAP APO if cur-
rently using only functionalities like product allocation or backorder
processing, which are already in the current 1809 release of aATP of SAP
S/4HANA.
However, a prestudy or an assessment is recommended to ascertain
whether all the functionalities (or system capabilities) for product alloca-
tion and backorder processing as used in GATP are present in the current
release (1809} of SAP S/4HANA or not.
As in the case of option 3, the customizing of classic ATP of SAP ERP also
will be useful; however, setup for product allocation and backorder pro-
cessing needs to be done in the SAP Fiori apps of aATP.
8 Existin g SAP ERP customer with SAP APO GATP
This customer can migrate partly to aATP in SAP S/4HANA and continue
using GATP in SAP APO. Customers using GATP in SAP APO very exten-
sively will not get all or similar functionalities of GATP in aATP, as of the
1809 release of SAP S/4HANA. For instance, if a customer uses substitu-
tion functionality (either location or product or both} in existing SAP APO

109
9 What's Next?

GATP installations, then they need to continue using SAP APO GATP even
if they migrate to SAP S/4HANA from SAP ERP.

Not e
SAP APO GATP can be integrat ed wit h SAP S/4HANA in a sim ilar way, as in the
case of SAP ERP, with same core interface, queued remote function cal l (qRFC),
and so on.

9 What's Next?
You've seen how aATP functionality in SAP S/4HANA manages variable
demand. Now take your SAP S/4HANA logistics journey further! Whether
you're curious to see what's new for logistics with SAP S/4HANA, or looking
to dive deeper into a particular logistics process, you'll find the resources
and guidance you need from SAP PRESS.

Recommendation from Our Editors

"' '"""' Reimagine your supply chain w ith Logistics with SAP S/4HANA:
: -:. &:..
;~·;.
ifOOe, 1 1~- •
An Introduction by Deb Bhattacharjee, Vadh i Narasimhamurti,
~~__:f;· :: ' ·"..i.. Chaitanaya Desai, Guillermo B. Vazquez, and Tom Walsh! See
~~· '"· ~~ what SAP S/4HANA offers for sales o rder management, man-
ufacturing, inventory management, warehousing, and more,
and discover how new SAP Leona rdo technologies impact
your supply chain.

Visit www.sap-press.com/4785 to learn more about Logistics


with SAP S/4HANA: An Introduction!

In addition to this book, our editors picked a few other SAP PRESS publica-
tions that you might also be interested in. Check out the next page to learn
more!

110
More from SAP PRESS

Production Planning with SAP S/4HANA: Learn how to configure production


planning in SAP S/4HANA for discrete, process, and repetitive manufactur-
ing, and run each using step-by-step instructions.
1010 pages, pub. 03/2019
E-book: $79.99 I Print: $89.95 I Bundle: $99.99
www.sap-press.com/4821

Materia ls Management with SAP S/4HANA-Business Processes and Configu-


ration: Configure and manage your key materials planning, procurement,
and inventory processes in SAP S/4HANA. Create purchase orders, run MRP,
use batch management, and more!
946 pages, pub. 10/2018
E-book: $79.991 Print: $89.95 I Bundle: $99.99
www.sap-press.com/4711

Sourcing and Procurement in SAP S/4HANA: Dive into SAP S/4HANA sourcing
and procurement functionality. Configure critical processes, from sourcing,
to invoicing, to supplier management and evaluation.
503 pages, pub. 01/2018
E-book: $69.99 I Print: $79.95 I Bundle: $89.99
www.sap-press.com/4551
SAP PRESS E-Bites
SAP PRESS E-Bites provide you with a high-quality response to your specific project need.
If you're looking for detailed instructions on a specific task; or if you need to become
familiar with a small, but crucial sub-component of an SAP product; or if you want to
understand all the hype around product xyz: SAP PRESS E-Bites have you covered.
Authored by the top professionals in the SAP universe, E-Bites provide the excellence
you know from SAP PRESS, in a digestible electronic format, delivered (and consumed) in
a fraction of the time!

Stefan Kienzle
Introducing Advanced Variant Configuration (AVC) with SAP S/4HANA
www.sap-press.com/4606 I $29.99 I 71 pages

Caetano Almeida
Introducing Materia l Requirements Planning (MRP) in SAP S/4HANA
www.sap-press.com/4649 I $24.99 I 72 pages

Caetano Almeida, Mahesh MG


Introducing Production Planning and Detailed Schedu ling (PP-OS) with SAP S/4HANA
www.sap-press.com/4582 I $24.99 I 61 pages

The Author of this E-Bite

Mrinal K. Roy is an SAP supply chain solution architect with more


than 17 years of experience in SAP. He has successfully led the design,
development, and implementation of several fu ll lifecycle SAP ERP,
SAP APO, SAP EWM, SAP TM, and SAP S/4HANA projects in various
countries. He is certified in SAP EWM, SAP TM, and six modules of SAP
ERP. He currently works for IBM as a subject matter expert and for the
global center of competency for SAP S/4HANA logistics projects across
the globe, with a special focus on advanced ATP, SAP EWM, and SAP TM.
Learn more about Mrinal at www.sap-press.com/4914.

You might also like