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.