Advanced Available-to-Promise (aATP) in S/4HANA 1610
Configuration (Part 1)
The S/4HANA 1610 release introduces advanced available-to-promise (aATP) with new functionality to better
execute order fulfillment and improve supply chain processes. This blog explains the detailed configuration
and master data settings necessary to implement the aATP process.
Before we explain the actions to set up the systems, we need to first address the larger questions:


What is the compelling reason my company should move to 1610 and purchase the aATP license?
What do I gain from this investment?
Let’s Begin with a Story…
Our company manufactures and sells toys based on licensing agreements with major movie studios, a business
with some hits along with a fair share of misses. This year we developed a toy elephant of the lead character,
Newton, in the animated movie . Immediately following the late summer release, our sales went vertical. The
movie turned into the megahit of the year, double the combined gross of the next three films, and global
demand for Newton was raging into the holiday season.
Quickly ramping up new contract manufacturer capacity, we still could not keep pace with the demand, raising
the proverbial “good problem to have” of more sales than we could satisfy. What could we do now? How
could we best prioritize our Newton stock to maximize our sales and profits? What solution could organize the
chaos before Newton became old news?
If we had the standard ATP, we could see sales and inventory for each plant and distribution center in the
network. With our global business, that is not enough. Global ATP perhaps? An improvement for sure, which
provides us with visibility across the network and allows us to allocate inventory via production and stock
transfers that can be pegged to sales orders. But is that sufficient for this situation? Or do we need something
better?
aATP to the Rescue
With aATP, the something better is here. Now we can achieve improved performance with the in-memory
S/4HANA platform, customize and execute our process with new Fiori apps and, most importantly, assign
inventory to our prioritized customers with the new “Win/Gain/Redistribute/Fill/Lose” strategies. These
powerful strategies are built into the system, running with the improved backorder processing (BOP) to ensure
our key accounts are delivered on time and in full, even with a last-minute, short lead-time order.
Ideally, we strive to fill all orders, but realistically that is not always feasible. This may mean we have to take
previously confirmed stock from a lower-priority customer and reallocate to fill the new higher-priority order.
Automation will drive the decisions more efficiently, identify and adjust to rapidly changing circumstances,
and fill orders with optimal business savvy, based on our own unique variables.
Whether we are selling toys, high tech, automotive, consumer products, or any number of other types of
business with rapidly changing dynamics, any product may have a shelf life equivalent to fresh fruit, with no
time to spare. Whether they are major accounts, higher-margin businesses, strategic relationships, or less-
critical channels, we can rapidly optimize our network and respond to changing circumstances to best suit our
business requirements.
How to Implement the aATP Process
Now, let’s get busy using our system, as Newton will reach brick-and-mortar store shelves and e-commerce
sites this week.
Our first task will be to Activate aATP functionality in our 1610 system. The IMG path is the first entry: SAP
Customizing Implementation Guide > Activate Business Functions.
In this object, open the folder S/4H_ALWAYS_ON_FUNCTIONS and scroll to the bottom. You will see the
entry S4H_AATP below and can confirm the activated status.
After activation, we proceed to sections of the initial configuration, which will appear similar, as these are
aligned with the standard ATP process from earlier ECC versions.
We begin by defining the Requirements Classes and Types with their assignment to specific Item Categories
and Schedule Line Categories. The documentation icons outlined in the screenshot provide detailed
descriptions of each IMG object for reference. The standard system will deliver core values with flexibility to
create new or update existing values as needed.
Following the IMG path: Sales and Distribution > Basic Functions > Availability Check and Transfer of
Requirements > Transfer of Requirements > and the subfolders displayed next.
Checking Groups make up the next section, with the IMG path: Sales and Distribution > Basic Functions >
Availability Check and Transfer of Requirements > Availability Check > Availability Check with ATP Logic
or Against Planning, followed by another set of subfolders.
We find an important change to Activate aATP within the first task, Define Checking Groups. Note the far
right column now lists two choices, Active and Blank. Set the indicator as appropriate for each Checking
Group.
When this configuration is complete, Checking Groups are assigned to each material in Master Data.
Checking Rules will be assigned to each Checking Group and this IMG object is available in several different
folders. We will follow this path to access the Checking Rules:
Cross-Application Components > Advanced Available-to-Promise (ATP) > General Activities for Advanced
Available-to-Promise (ATP) > Stock Movements > Set Up Dynamic Availability Check. Four different buttons
are within this structure, where we again begin with standard values and make adjustments as needed.
After the Checking Rules are established, we proceed to Product Allocation setup. These values guide the
system in deciding how inventory per material is confirmed for sales orders. The first step is to define the
Allocation Procedure, followed by further definition details in the remaining folders. Once complete, these
procedures are assigned to each material via master data.
Sales and Distribution > Basic Functions > Availability Check and Transfer of Requirements > Availability
Check > Availability Check Against Product Allocation > followed by a group of subfolders.
We will complete each of the objects listed, beginning with Maintain Procedure:



Planning Version 000 is required and can be created with MC93 and Planning Type COMMIT
Planning Hierarchy is also required and created with MC61
For the object “Process Flow for Each Schedule Line Category,” there are three check boxes to activate for
all Schedule Line Categories that will use aATP:
The last task in this section is the Check Settings in Product Allocation item. This is a system check to identify
any errors that will prevent proper functionality: red messages equal errors. You can click any line item to
display the error and corrective actions.
Moving forward, we now open the new IMG path for aATP: Cross-Application Components > Advanced
Available-to-Promise (ATP), where we see six folders, each containing further setup points. We can skip the
Product Availability Check folder, as this has repeated settings that we completed earlier.
1.
General Activities for aATP:


This folder has four subfolders, two of which contain duplication updated earlier.
Opening the new folders, for Production/Process Orders and Stock Transport Orders, we define the aATP
settings to guide the system in these two areas.
2. The Product Allocation folder contains the essential on/off switch to activate Allocations. We also have
optional number ranges that we can create as needed. The Documentation icon also provides further details
to validate all applicable settings.
3. The folders Backorder Processing and Rules-Based Availability Check contain default settings that apply to
most common scenarios, but can be revised if desired.
4. Optional BAdIs are available in the Business Add-Ins (BAdIs) for Advanced Available-to-Promise (ATP)
folder.
The last IMG task requires updating the Logistics Information System (LIS) control for the Product Allocation
Info Structure S140. IMG path:



Logistics > General > Logistics Information System (LIS) > Logistics Data Warehouse > Updating >
Updating Control > Activate Update for the Sales and Distribution item
Select S140 and display the details
Set to Updating radio button to Synchronous Update
With our IMG activities completed, we next change applicable Material Master records with two settings:
Product Allocation Procedure on Basic Data 1 and Checking Group on Sales General/Plant or MRP 3.
Our remaining task is to implement three SAP Notes that will set up the HANA Rules Framework (HRF) and
Business Rules Framework Plus (BRF+ necessary for BOP operations. Further details are included within each
note.



2400537: Backorder Processing in Available-to-Promise (ATP) in SAP S/4HANA
2345697: BRF+ analytical decision table check Call CL_FDT_XS=>GET_INSTANCE with RFC
destination
2351188: BRF+ Analytical function generation – Derive default schema dynamically
Now that we completed the detailed configuration, activated aATP and Product Allocations, and revised our
Master Data, we are ready to move forward with the transactional data to put the aATP process in motion.
Advanced Available-to-Promise (aATP) in S/4HANA 1610
Execution (Part 2)
Follow RSS feed Like
3 Likes 7,454 Views 12 Comments
In case you missed our first SAP Tech Tips blog, we documented the detailed aATP configuration, activated
Product Allocations, and updated Master Data to set the foundation for running with aATP in our new S/4
HANA 1610 system. With business benefits identified to improve our order management, we are ready to
move forward with the transactional data to put the aATP process in motion.
Increase Logistics Efficiency with aATP
Initially, we will set up the Product Allocation Objects using 3 Fiori apps. These Objects establish the
selection parameters and build the foundation for the Back Order Processing (BOP) that we will create later in
the process. Details on these 3 apps will be explained in a separate blog to be published within a few weeks.
We next proceed to four BOP apps that will create the parameters to decide what inventory is allocated to
certain sales orders. The first BOP app, Configure BOP Segment, creates specific components that will be
incorporated into the larger planning landscape. These segments will filter and sort data per the selection
criteria documented. As an example, we can select Sold to Party to include a customer’s orders within a
segment. There are a host of standard options available, such as Sales Organization, Document Type, Date
Ranges or Plant, providing broad flexibility in segment creation. Once complete, a segment may appear as
shown below, where we are selecting all orders shipping from the Supplying Plant 1710.
A display of the Fiori screen to build segments is shown below. This displays a few of the Selection Criteria
choices available.
The second part of Segment Creation is the Prioritization. The Prioritization defines how the confirmed
quantities will be redistributed among the orders identified from the Selection Criteria setting. There are 30
choices for this value, which display in a list similar to that shown above, and you can also build them in a
series by adding multiple Prioritizer attributes into your segment. For our example, we will select Delivery
Priority, the Sort Order = Ascending, and Save the BOP Segment. When complete, the BOP Segment appears
as shown below.
With this BOP Segment, we are instructing the system to take all of the Documents within Sales Organization
1710 and distribute the confirmed quantities based upon their Delivery Priority, with Priority 1 first, 2 second,
and so forth.
After we identify the Selection Criteria and Sort priorities, we save each segment.
The next BOP app, Configure BOP Variant, will provide the key tool to drive the aATP functionality. We
build a variant by adding any number of the segments created above to drive system adjustments. The
important step is the strategy we select. Summarized below are the five new categories to adjust confirmations,
displayed in their order of merit:





Win: These orders are confirmed in full/on time as the top priority
Gain: Maintain initial confirmation and possibly gain up to the full quantity
Redistribute: Middle ground that should gain but may also lose confirmed receipts depending on the two
factors above
Fill: Will not increase confirmed quantity, can either keep current or lose
Lose: All confirmations will be deleted and assigned to higher priorities
The slide picture below demonstrates how each strategy can acquire inventory from the lower-priority
strategies.
In our example, we will select the Redistribute strategy, and add one segment into our BOP Variant. You can
add multiple Strategies and segments with the buttons in the display below based upon your business
needs. Once complete, save your BOP Variant.
With BOP Variants created, we move on to the Schedule BOP Run app, containing multiple Scheduling
Options for one time runs or the more common scenario of Background jobs running periodically. This app is
also available as a GUI transaction, ATP_BOP. For our example, we will select our BOP Variant created
earlier and the Start Immediately option to run it one time.
Clicking the “Schedule” button starts the actual BOP job.
The last BOP app, Monitor BOP Run, is a report to display the completed jobs and the business impact for
each one. Users see the Processing Status and Confirmation data with %s indicating where confirmed
inventory changed based upon the Variants within the job. This data is also visible in SM37.
We can click a Variant Name to drill down into a specific job run to analyze data further. In this example we
see an improvement, no change, and a decrease for three sample materials.
Clicking a Material Number, we drill down further to identify Sales Order level changes. We can see Sales
Order 21 gained an additional 90 pieces to now be confirmed in full.
In this blog, we reviewed the different Fiori apps used to schedule, execute, and monitor the aATP process
including steps to create the building blocks.
Product Allocation Configuration:
Product Allocation Configuration in SAP
Executive Summary:
A precise planning and controlling mechanism is of the utmost importance for the execution
of competitive order processing with guaranteed efficient and timely delivery to the customer
of the required order quantity. Unforeseen problems, such as production deficits or increased
demand can have critical consequences for order processing and must be brought under
control as soon as possible.
Product allocation is a function provided by the R/3 system for carrying out these control
options intended to help your company to avoid critical requirement and procurement
situations. This should enable you to keep production to a minimum at the same time as
allowing you to react quickly to bottlenecks and changing market situations.
The screenshots provided in the document for illustration are taken from a SAP ECC 6.0
system. These illustrations may vary in part or full in other version of SAP.
Table of Contents:
Introduction: 4
Product Allocation Configuration. 5
SYSTEM RUN THROUGH……………….………………………………………………………………….19
A. References. 20
Introduction:
Product allocation functionality allows one to manage the supply of products which do not
follow a fixed pattern of supply. The system can perform availability checks together with
product allocation checks. In Production allocation, you can allocate quantity for specific
materials at various hierarchical combinations and in turn reserve these quantities for these
characteristics. These characteristics or hierarchical combinations can be either the sales area
data or this can go even up to customer groups or customer level.
Another way to explain the business functions that product allocation functionality can meet
is as follows:
1. 1.
If the demand is greater than the supply, product allocation functionality provides
the ability to distribute supply evenly to the customers and also within the company’s
manufacturing capacity
1. 2.
It also helps in reserving certain quantities for specific customers who are important
to the company in the scenario where there is supply constraint and usually the supply is
less than the demand.
As per the client requirement, we had configured the product allocation on monthly basis.
Requirements for Product Allocation:
For carrying out availability check for product allocation, some requirements must be met:

Material Set Up in SAP Material Master
As shown in the above screenshot, product allocation determination procedure must be
entered in the basic data tab.

Statistics update
At the customer, material and header level, it is required that during customization for
Logistics Information System, statistics updating and update group must be set for the IS
Step by step Product Allocation Configuration:
Step 1: Creating Key Figure Catalogue – (MC18)
The field catalog contains the fields that are can be used for the rules-based availability
check and product allocations. These fields are present in the selection criteria to check the
table update after order or delivery creation.
We have maintained “ZZKE” for Key figure Catalogue. This contains fields which are
updated after order creation. “ZZCH” contains characteristic catalogue which contains fields
for which the data is maintained for the Product allocation check to get activated.
Path: IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Data Basis -> Field Catalogs -> Maintain Self-Defined Field Catalogs
Step 2: Define Information structures – (MC21)
Path: IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Data Basis -> Information Structures ->Maintain Self-Defined Information
Structures
Step 3: Setting Parameters for Information structures and Key figures (MC7F)
We maintain the planning method in this step by specifying the planning periods for e.g. it
can be either Weekly or Monthly.
Path: IMG -> Logistics-General -> Logistics Information System (LIS) -> Planning -> Master
data -> Set Parameters for Info structures and Key figures
Step 4: Maintain Update Groups –
It is the update rule to process the order data to the table.
Plan: IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Updating -> Update Definition -> General Definition Using Update Rules ->
Maintain Update Groups
Step 5: Maintain Update Rules – (MC24)
Update rules consist, for example, of the source field, the event which triggers the update,
requirements and formulas. Once we have defined the update rules, the corresponding
update programs are automatically generated.
The maintenance screen lists all of the key figures in the information structure for which you
can define update rules. If no update rules have been defined by the time that updating is
created, then all available information from the information structure definition will be
proposed.
Path – IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Updating -> Updating Definition -> Specific Definition Using Update Rules ->
Maintain Update Rules
a.
a. Incoming Orders Qty (Confirmed Qty)
Characteristics for Incoming orders qty
a.
b. Order Quantity
Characteristics for Orders qty
a.
c. Delivery Quantity
Characteristics for Delivery quantity
Charateristics for Delivery quantity
Step 6: Activate Update – (OMO1)
This is required as to update the table with order details, material information and to
cross check if the order placement is possible or the limit for each customer is reached. Here
we must specify the allocation period and type of updating for each update parameters.
Path: IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Updating Control -> Activate Update
Step 8: Assignupdate group at item level – (OVRP)
Path – IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Updating Control -> Settings: Sales -> Update Group -> Assign Update Group
at Item Level
Step 9: Assign Update group at header level – (OVRO)
Path – IMG -> Logistics-General -> Logistics Information System (LIS) -> Logistics Data
Warehouse -> Updating Control -> Settings: Sales -> Update Group -> Assign Update Group
at Header Level
Step 10: Create product allocation procedure – (OV1Z)
This procedure must be mentioned in the material master. Procedure must be assigned to
the Info structure in the product allocation hierarchy. A criterion for planning hierarchy is
determined by info structure. The product allocation is stored in the planning hierarchy.
Several objects with different validity periods can be assigned to the procedure.
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation ->
Maintain Procedure
Step 11: Define Allocation Object –
This object is used in Product Allocation Determination Procedure. Product allocations are
stored in planning hierarchy by allocation object. This object has to be assigned to the
product allocation procedure for the product allocation to be carried out.
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Define
Object
Step 12: Specify Hierarchy – (OV3Z)
In this, info structure is assigned to product allocation procedure to display statistical
structures. Planning hierarchy is determined according to assignment of allocation object
and info structure to product allocation determination procedure.
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Specify
Hierarchy
Step 13: Define consumption period for product allocation –
We have to define (past and future) consumption periods for product allocation quantities. If
we want to restrict allocation for current month or week, we keep backward and forward
consumption data (as seen in the below screenshot) as blank so that it checks only for current
month/week.
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Define
Consumption Periods
Step 14: Setting Validity period – (OV4Z)
In this step it we define the validity of the product allocation object to be determined at the
time of order/Delivery creation.
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Control
Product Allocation
Step 15: Define Transfer of Requirements – (OVZ0)
In this it is determined whether availability check should be run for product allocations or not.
It can be determined in each requirements class
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Define
Flow According to Requirement Category
Step 16: Define Schedule line categroy for Product allocation – (VOV6)
In this it is determined whether or not availability check is to be carried out for the
respective schedule line category.
Path – IMG -> Sales and Distribution -> Sales -> Sales Documents -> Schedule Lines ->
Define Schedule Line Categories
Step 17: Define process flow for Schedule line category –
Path – IMG -> Sales and Distribution -> Basic Functions -> Availability Check and Transfer of
Requirements -> Availability Check -> Availability Check against Product Allocation -> Process
Flow for Each Schedule Line Category
Step 18: Create Planning Type – (MC8A)
Path – IMG -> Logistics-General -> Logistics Information System (LIS) -> Planning -> Tools
-> Maintain Planning Types
Step 19: Planning Hierarchy – (MC62)
To enable product allocation, you need to add a member in LIS via Tcod MC62. Selected
Planning hierarchy on menu path and click Revise. Specify the info structure S750 and set
radio button “Add member”.
Here we have maintained the proportion as 100%, which can be modified as per the
requirement.
The total for a product group should always be 100% hence the masking character percentage
is mentioned as 0.
Now, we go to tcod MC63 in display mode and specify the Product allocation object and Sales
district.
We can see the Sold-to-party were listed here since we added just now.
As of now, the Sold-to-party already added to Info structure. We need to maintain a quota to
this Sold-to-party for product allocation limitation.
We can do this in MC94. Specified the Product allocation object, Sales district, Sold-to-party
same as before, and select Inactive Version.
For below instance, we put quota 20 units in Month of august and save this change.
MASKING –
In certain cases, the same product can be used for multiple customer and cutomer tier
combination. For this instead of maintaining the same sales area and material combination
for multiple ship to party, we mask the fields for ship to party and customer tier.
This is done as per the below screenshot:
Thus the above allocation will be valid for all the customers allowed in the above mentioned
sales area and material combination.
System Run Through –
Material VRCLTESTB is assigned 20 quantities for particular sales area combination.
Creating an order –
The “On Order quantity” chagned from 46 to 47 –
After Delivery creation, change in Delivery quantity seen –
MC94:
This transaction gives the details of the allocation quantity, cofirmed, order and delivery
quantity for a particular sales area and material com
Creating an order after the allocation quantity and confirmed quantity are equal:
The Confirmed quantity is seen as zero as the quantity is exceeding the allocated quantity.
As mentioned earlier, client requirement for monthly product allocation and delivery quantity
updation were carried out after making changes in the routines.
Routine changes were made to meet client requirements.