SAP S/4HANA Advanced Available-to-Promise (aATP) is a critical component of the S/4HANA suite that enhances the standard ATP (Available-to-Promise) functionality with more advanced and flexible features. It is designed to meet complex order fulfilment processes and ensure higher accuracy and efficiency in inventory allocation and customer order management.

Key Features and Functionalities of aATP

Product Allocation (PAL)

Product Allocation (PAL) in SAP S/4HANA’s Advanced Available-to-Promise (aATP) is a feature that enables businesses to control the distribution of limited products or resources across various customers, channels, or regions. It ensures that constrained products are allocated according to established rules and priorities, preventing overselling and ensuring that key customers or markets receive an appropriate share.

• Purpose: Ensures products are distributed according to predefined rules and limits, preventing overselling and prioritizing important customers or channels.
  
• Process: During order processing, the system verifies these allocations to determine the amount of product that can be confirmed for each customer.
  
• Benefits: Aids in managing limited products, balancing supply and demand, and safeguarding key customer relationships.

In aATP following aaps are applicable for product allocation –

• Configure Product Allocation
  
• Manage Product Allocation Planning Data
  
• Manage Product Allocation Sequences
  
• Assign Product to Product Allocation
  
• Product Allocation Overview

Concepts of Product Allocation (PAL)

1. Product Allocation Object (PAO) steps

• The core of PAL is the Product Allocation Object (PAO), which defines the framework and scope for allocation. It includes relevant materials (products), customers, customer groups, and parameters such as sales organizations or regions.
  
• A PAO simplifies the grouping and management of allocation rules.
  
• The Configure Product Allocation app is used to set up a PAO, allowing you to incorporate various characteristics into the product allocation object.
  
• The first step involves defining allocation rules within the PAO, which includes establishing relevant dimensions (such as products, customers, and regions) and assigning quotas. Allocation rules are time-phased, meaning they can vary across different periods (e.g., weekly, monthly).

Example Scenario

Imagine a company that manufactures a highly demanded mobile phone but has limited production capacity. The company has key customers across various regions and wants to ensure fair distribution to each region. To achieve this, the company creates a Product Allocation Object with rules that allocate specific quantities to each region based on historical sales data and strategic priorities.

Order processing: When orders are placed from different regions, the system checks the available allocation for each region before confirming the order. If a region’s quota is exhausted, no additional orders from that region will be confirmed unless the allocation is increased or unused quotas from other regions are available for redistribution.

In this example, instead of using regions, the allocation is based on a combination of sales organizations and sold-to parties.

Created product allocation objects –

With required characteristics –

2. Product allocation sequence

In our example Mobile allocation sequence consists of two sequence groups in a specific order. This order ensures that we first attempt to fulfil the requested quantity from the specific allocation per customer. If the allocation quantity is insufficient, the system will then use the second allocation during the Available-to-Promise (ATP) check. Consequently, important customers have access to two pools, while other customers can only use the quantity from the general pool.

The capacity sequence section contains a single sequence group that represents transport capacity. This group includes two allocation objects—one for the trailer and one for the battery. During the ATP check, all constraints within a sequence group are considered using AND logic.

3. Allocation planning

• Allocation rules are the core of PAL, determining how much of a product can be allocated to different customers or groups. Quotas are set based on historical data, forecasts, or strategic priorities.
  
• These rules can be time-dependent, allowing businesses to adjust allocations based on seasonal demand or other factors as per their business relevancy.
  
• For this ‘Manage Product allocation Planning data’ app is available where we can allocate the quantity.

Creation of Product allocation objects –

Planning data to be setup for each allocation object –

MOBILE_STANDARD_SALES

Capacity Sequence is nothing but the available capacity –

Planning data setup for MOBILE_TRANS_CAPACITY –

4. Assign product to Product allocation –

Product allocation output

Sales order creation to check confirm quantity after PAL set up. As per below scenario even though my capacity is 30 system has considered 15 qty after considering sequence and planning data by considering current period.

The actual ATP quantity is 100 in the system but system is showing confirm quantity in sales order after Product allocation setup,

5. Product allocation overview app–

This will give end to end overview of product allocation and order confirmation.

Integration with Other aATP Features

• Backorder Processing (BOP): PAL works in conjunction with BOP to reallocate inventory to high-priority orders if the allocations allow.
  
• Supply Protection: PAL can be used in combination with supply protection to reserve inventory for specific customer segments or markets, ensuring that critical orders are always fulfilled.

Benefits of Product Allocation (PAL)

1. Prioritization of Key Customers: PAL ensures that key customers or markets receive the products they need, even in situations of limited supply.
   
2. Controlled Distribution: Prevents overselling by enforcing quotas and ensuring that sales commitments are within the limits of available resources.
   
3. Flexibility and Responsiveness: Time-dependent allocation rules allow businesses to adjust to changing market conditions, seasonal demand, or strategic priorities.
   
4. Improved Decision-Making: Real-time tracking of allocation consumption provides actionable insights for sales and operations teams, enabling better decision-making.

The post Advanced Available – to – Promise (aATP in S/4HANA) appeared first on ERP Q&A.

We utilize ChangePointer in SAP to mirror changes in main data (customers, vendors, materials) visible to other clients listed in the customer distribution model through ALE/IDOCs. ChangePointer is based on a change document technique monitoring alterations in essential documents such as materials, customers, vendors, and sales orders. Modifications in a document are logged in the CHDHR table, and additional change markers for ALE-related changes are written in the BDCP table. The BDCPS table stores the status of processed or unprocessed modified documents. SAP maintains change documents for various objects including materials, customers, invoices, and bank data to track audits of changes made within an object. Each change document object represents a set of tables recording the changes. For example, a change document for material master data, named MATERIAL, includes various tables like MARA and MARC. When an application process makes a change in an object, it writes change documents stored in CDHDR and CDPOS tables for each modification.

More Info: SAP Data Integration with SAP Data Services Certification

STEP 1: SCDO

Execute the SCDO transaction to view a list of change document objects and their tables. The Shared Master Data (SMD) tool writes change markers. When a change is made in an object, the SMD tool checks ALE settings and refers to the ALE distribution model to determine if the receiver is interested in the changed object. If a suitable recipient is found, the system creates a changepointer in the BDCP table, indicating changes documented in the CDHDR table. ALE programs analyze changepointers and generate IDocs. SAP provides standard function modules that read the changepointer table and generate IDocs for modified objects. These programs are designed to ignore multiple changes, creating only one IDoc. For example, if a material is changed four times before the function module is called, only one IDoc containing the latest data from the material master is generated. These function modules are called by the standard program RBDMIDOC. This report’s selection parameters allow specifying the message type for analyzing change markers. To enable master data distribution based on changes in the Configuration Object, the following configuration steps should be applied. For our example, we selected the object related to customer changes.

STEP 2: BD61

This option enables the general change marker function. If it’s not active, it should be activated.

STEP 3: BD50

In this step, we need to activate the IDoc types suitable for our ChangePointer functions. For customer master data, we have activated the DEBMAS IDoc types.

STEP 4: BD52

For standard main data objects like materials, customers, and vendors, SAP already provides a list of fields where changepointers are written. If you are satisfied with the standard field group, this step can be skipped. If you want to add new fields, you need to enter the required fields. If you are not interested in creating IDocs for changes in a specific field, you can remove it from the list. For example, if you do not wish to distribute the material master list for changes in the Catalog Profile (RBNRM) field, you can delete this entry from the table.

STEP 5: SE38

Run the RDBDMIDOC program to initiate an IDoc creation process. Specify the message type on the selection screen, such as MATMAS. After executing, it displays the number of processed entries.

Note: Typically, this program is set up as a job to run frequently and start creating IDocs for various message types.

STEP 6: WE02

Use this to check the status of IDocs.

————————————————————————————————————————

To ensure the proper functioning of the established ChangePointer, it’s necessary to complete the logical destination steps, which include:

STEP 1: BD54

A logical destination name is assigned.

STEP 2: WE20

A logical destination profile must be defined. Here, we adjust the partner type according to our needs, placing it under ‘LS’. We also add our IDoc preferences in the output parameters.

STEP 3: BD64

Distribution and filtering settings are created for the established logical destination.

Subsequently, after the job setup and the changes made, IDocs are triggered.

Thus, with the logic of ChangePointer, changes in the main data can be sent to external systems without the need to create a program.

The post Changepointer for SD Customer Master Data appeared first on ERP Q&A.

Questions

• How to handle global key accounts whose subsidiaries are not bound to a sales area?
  
• Is it possible to only maintain price condition once and automatically determine the specific price from global key account to its subsidiaries in different sales areas?

Solutions

SAP S/4HANA cloud customer hierarchy supports 3 types of subnotes:

• Subnode: This is a text node that can be customized based on your business needs. It can contain multiple subnodes.
  
• Subnode – Business Partner: This is a business partner node, which can contain subnodes. The system auto-checks that the business partner added to the hierarchy belongs to the same sales area.
  
• Business Partner: This is a business partner node, however, it is a leaf node and cannot further contain any nodes. The system auto-checks that the business partner added to the hierarchy belongs to the same sales area.

As text note is not bounded to a single sales area and can be marked as pricing relevant, it can be used as global key account to reduce the efforts for pricing condition maintenance.

Here is an example on how to do it step by step:

1. Adapt system configuration – Create a condition table (e.g.886 )without sales area data fields.

2. Adapt system configuration – Assign this new condition table 886 to a price access sequence (“ZCHT Customer Hierarchy Testing”).

3. Adapt system configuration – Maintain pricing procedure

Copy your existing pricing procedure to a new one(e.g.“ZCHT01”) and add the access sequence (“ZCHT Customer Hierarchy Testing”) into the new pricing procedure(e.g.“ZCHT01”).

4. Adapt system configuration – Set Pricing Procedure Determination.

Update the pricing procedure determination of related sales areas to use the new pricing procedure (E.g. ZCHT01”)

5. Adapt system configuration – Assign Customer Hierarchy Relevance to Sales Document Types
Make sure the customer hierarchy determination has been enabled for related sales document Type.

6. Maintain master data – Create customer hierarchy.

Create two customer hierarchies using text note as global key account (e.g.” KEYACCOUNT”) using Manage Customer Hierarchies App. Make sure the hierarchies have been activated before usage.

7. Maintain master data – Create price condition record.

Create price condition records for the key account (E.g. 15% discount for KEYACCOUNT)

Now create sales orders for customers (E.g. customer 17100001, 10100005, 10100003) under customer hierarchy KEYACCOUNT, the 15% discount will apply.

And you could also check the details via Analysis Pricing.

The post How to support global key account with S/4HANA Cloud customer hierarchy? appeared first on ERP Q&A.

In S/4HANA Cloud, the SAP best practice content provided by SAP normally fulfills basic E2E business requirement. Different from S/4HANA On-Prem or S/4HANA Private Cloud where customer has full access to the backend system (e.g. SPRO) to change configuration, customer uses SSCUI apps to change some configuration settings in S/4HANA Cloud. However, most SSCUI settings are only defined in the design time and it is difficult to handle different process variants in Q2C order process.

With help of CPF tool (Configurable Parameters & Formulas), it is possible to define business rules in S/4HANA Cloud to influence different aspects of sales order process at runtime.

SAP Business Rule Framework plus (BRFplus) is widely used in different area of SAP products. There is also possibility to utilize BRF+ to allow customer define flexible business rules via BRF+ in CPF application.

This blog shows CPF usage “S03” to determine pricing date on sales order header based on business rules defined by BRF+.

Business Example

Customer wants to define complex business rules to determine pricing date on sales order header. Comparing with the approach of CPF decision table, customer would like to utilize the capability offered in BRF+ to define business rules. For example, customer can not only define decision tree to influence pricing date, but also write logical expression to determine pricing date.

In this example, I’d like to show detail steps of generating BRF+ application for CPF usage and define business rules via BRF+ to determine pricing date.

Configuration Details

As of now, the BRF+ approach is not ye supported in S/4HANA Cloud. For some CPF usages, the BRF+ option is offered in S/4HANA OP2021. Therefore, I am testing BRF+ features in S/4HANA OP2021 version.

By the way, there is plan to enable BRF+ approach on S/4HANA Cloud. Please stay tuned for new features on S/4HANA Cloud for CPF improvement.

Since customer is able to access IMG on S/4HANA On-Prem, it is possible to access to CPF configuration from IMG.

Create BRF+ Application

Go to following IMG path to create BRF+ application.

System navigates to the BRF+ workbench. Create a new BRF+ application and provide required information.

Save the BRF+ application and activate it.

Keep the BRF+ application like it, do not create BRF+ function now because the BRF+ function and other objects will be generated from CPF later.

Define Factory Calendar Determination Rule

Open following IMG node to define factory calendar determination rule.

Define a factory calendar rule and specify the source priority

Define CPF Parameter Catalogs

Open following IMG node to define parameter catalog for pricing date.

There are some standard parameter catalogs available for CPF usage “S03”. Customer can directly include these parameter catalogs to build up business rules in CPF.

In my example, these standard parameter catalogs are sufficient. But it is still possible to add new parameter catalogs by user, e.g. adding custom fields as available parameter catalog.

Assign BRF+ Application to CPF Usage

Open following IMG node to assign existing BRF+ application to CPF usage. The BRF+ application was already created in previous steps.

It is possible to use search help to find out the BRF+ application.

Save the entry and mark this BRF+ application as default.

Define CPF Formulas with BRF+

Open the following IMG node to define CPF formulas for pricing date determination.

Define a new formula

Select the formula ID and click sub-folder “Assign Formula Parameter” to add parameter catalogs to CPF formula

In this example, sales org, sales office and sales group as selected to build up business rules in CPF.

Double click the sub-folder “Assigned Usage Task” to link BRF+ application to CPF usage task.

The CPF routine “2” represent the BRF+ is used to define business rule. Click the button in left top to generate BRF+ function.

In the pop-up dialog box, name the BRF+ function and click button “Generate and Save”. The BRF+ objects are generated automatically.

Define Business Rules in BRF+

Create the Ruleset in BRF+ function.

Then click button “Create And Navigate To Object” to define rules in rule set.

Create a rules in ruleset based on different sales document types.

In this example, I created two rules for sales order and sales quotation. Navigate to the rule of sales order to create expression.

Create a decision table for sales order and select the columns as below to build up decision table.

Then define the business rules in decision table.

In the business rule, the offset 7 days is defined for sales org 1010/sales office 100/sales group 100 combination, which means when sales org, sales office, and sales group combination in sales order matches CPF rule, pricing date will be determined with +7 days.

Activate the decision table and simulate the business rules. For example, use following input value to simulate business rule defined in BRF+

Execute and display the processing steps

The offset value “7 days” is determined for sales org 1010, sales office 100 and sales group 100.

Define Custom Routines for Pricing Date Determination

Open following IMG node to define custom routine for CPF formula of pricing date determination

Create a new custom routine for pricing date determination

Click the line and double click the sub-folder to assign CPF formula to custom routine.

Assign Custom Routine to Sales Document Type

Open following IMG node to assign custom routine number to sales document type.

The custom routine “3000001” defined in previous step is assigned to sales document type “OR”.

Save the entry.

Test BRF+ Rules in Sales Order

Go to transaction VA01 to create sales order. Provide required information to create a sales order.

Because the business rule defined in BRF+ is not matching, the current date is determined as pricing date.

Go to sales order header to change the sales office to 100 and sales group to 100 which match to business rule defined in BRF+.

After the sales office and sales group are changed, the pricing date is re-determined according to business rule maintained in BRF+. The pricing date is calculated with considering public holiday.

Save the sales order, and calculated pricing date is persistent in sales order.

Create another sales order, make sure the combination of sales office and sales group doesn’t match to business rule defined in BRF+.

The default pricing date is calculated. The business rule defined in BRF+ is not functional here.

The post S/4HANA Q2C Sales Flexibility: Using BRF+ to Determine Pricing Date appeared first on ERP Q&A.

You can configure and manage workflows for sales rebate processing such as the approval processes for condition contracts and settlement documents and the release of condition contracts for settlement.

Depending on the workflow you want to manage, you open the Manage Workflows for Condition Contracts app or the Manage Workflows for Settlement Documents app.

To create a new workflow, on the Manage Workflows screen, you make sure that the workflow you want to define is selected and then choose Add. You can then define the workflow steps, start conditions, and exception handling.

Manage Workflows for Condition Contracts

With this app, you can manage workflows related to condition contracts, such as condition contract release and condition contract release for settlement.

Manage Workflows for Settlement Documents

With this app, you can manage workflows related to settlement management documents, such as settlement document release.

Condition Contract -> Settlement Release of Condition Contract

• Manage Workflows for Settlement Documents -> Release of Settlement Document

In order to automate processes in Settlement Management with workflows, you first have to make settings in the Manage Teams and Responsibilities app.

Check the transaction SWE2 in SAP GUI if Workflow Linkage is setup

Create Contract Process Variants and assign to Contract Type

Before you can manage workflows for Settlement Management, you need to define condition contract process variants to which you assign contract types.

SPRO->Logistics General -> Settlement Management -> Condition Contract Management -> Condition Contract Maintenance -> Define Condition Contract Process Variants.

Activate Condition Contract Approval Process

SPRO->Logistics General -> Settlement Management -> Condition Contract Management -> Condition Contract Maintenance -> Define Condition Contract types

Disable Automatic Accounting document generation of Settlement document

SPRO->Logistics General -> Settlement Management -> Settlement Documents -> Document Types

Enable Condition contract Event Management

Define Status Groups

SPRO->Logistics General -> Settlement Management -> Settlement Process -> Define Status Groups with Application Statuses

Define Settlement Process Types

SPRO->Logistics General -> Settlement Management -> Settlement Process -> Define Settlement Process Types

Authorizations in Settlement Management

You can implement an authorization check that precedes the creation of accounting (FI) documents to ensure that only designated employees can release settlement management documents to Financial Accounting. This function allows you to meet security and legal requirements.

SPRO -> Logistics – General -> Settlement Management -> Basic Settings -> Specify Extended Scope of Settlement Management.

Authorisation Objects W_WBRK_ORG , W_WBRK_FKA & W_WBRK_STS check for Authorization of users during processing of Settlement Documents created out of Condition Contracts. The access for Release to Accounting and Reversal of Settlement document can be managed with these objects.

Authorisation Objects W_COCO & W_COCO_ORG check for Authorization of users during processing of Settlement Condition Contracts. The access to Release condition Contracts can be managed with these objects.

Once above mentioned setup is in place, you can now proceed to test the end to end workflow process as below.

Open the Condition Contract in change mode and Click on Request Approval and save document.

Release Condition contract from the Workflow approval box.

The condition Contract will now be seen as active.

Open the Condition Contract again in change mode, and Lock Settlement and save document.

Open the Condition Contract again in change mode, and request Settlement Approval and save document.

Release Condition contract for Settlement from the Workflow approval box.

Settle the condition Contract for Delta OR Partial or Final Scenario.

Request for settlement document release via workflow. Go to status and click on “Workflow release required”, assign the status and save document.

Approve Settlement document from the Workflow approval box.

Release the settlement document to accounting.

The post Flexible Workflows in Condition Contract Management appeared first on ERP Q&A.

This blog is for SD consultants. This functionality can be used from SAP S/4HANA OP2021 FPS00 version and OP2020 as well.

What is Supply Protection

Supply Protection is for promised minimum selling quantities for each customer.

Pre-requisite

SAP S/4HANA OP2020 FPS00 or upper version. Fiori server must be installed. The user must have “SAP_BR_ORDER_FULFILLMNT_MNGR” role.

Customizing

IMG>Cross-Application Components>Advanced Available-to Promise(aATP)>Product Availability Check(PAC)>Define Availability Check Group

Advanced ATP is activated at “Availability Check Group”.

IMG>Cross-Application Components>Advanced Available-to Promise(aATP)>Product Availability Check(PAC)>Configure Scope of Availability Check

“With Supply Protection for Specific Document Types” flag should be On

Setting

Execute App ID:F4569 “Manage Supply Protection”

Click Create button.

Set the mandatory fields.(Red * Marked)

Supply Protection is defined by Material and plant combination.

*“Consumption Based on” can be done as “Requested Delivery Date” from SAP S/4HANA OP2021.

Set planning Period Type, start date and end date.

Set Characteristic 1 is mandatory. You can define up to two characteristics for Core Protection ( Horisontal) .

You can add additional fields of Sales Orders and Stock Transfer Orders via “Characteristic Catalog” Fiori Apps.

Prioritized Characteristic is option. You can define over 2 characteristics, if you need.

Push create button and set characteristics.

Set Priority, the Characteristic Values and the Protected Quantity

Push Create button and set characteristics if you use Prioritized Characteristics.

And set protected Quantities for each period.

Push Create button.

Push Activate button.

Create Other Supply Protection objects for other Sales Offices as well in this case.

Case: no Prioritized Characteristics

Set protection group values

Finally I created 3 supply protection objects

Operation

Execute “Create Sales Orders VA01” Fiori Apps.

Set Sales Order Type, Sales Area and Sales Office.

Set sold-to party and Customer reference number.

Set material number and quantity.

Push enter key.

Then “Review Availability Check” (Only for Fiori Apps”Create Sales Orders VA01″ From OP2021) screen appears, in this case confirmed quantity is 950 pcs. Push “>” button.

Then, click “Intermediate Results”.

Click

Click

Click “Show Details for Supply Protection”

You can see “Review Supply Protection Check Result”.

Let me explain why the confirmed quantity is 950 pcs.

Because confirmed quantity for Sales Office 170 and Customer Group 01 Sales Order

3000(inventory)- 1050(Sales Office 17A) – 1000(17B) = 950 pcs

Change sold-to-party from ZSUP_CUSA(Customer Group 01) to ZSUP_CUB(Customer Group 02).

Because confirmed quantity for Sales Office 170 and Customer Group 02 Sales Order

3000(inventory) – 500(170 & Customer Group 01) – 1050(Sales Office 17A) – 1000(17B) = 450 pcs

Change sold-to-party from ZSUP_CUSB(Customer Group 02) to ZSUP_CUSC(Customer Group 03).

Because confirmed quantity for Sales Office 170 and Customer Group 03 Sales Order

3000(inventory) – 500(170 & Customer Group 01) – 500(17A & Customer Group 02) – 1050(Sales Office 17A) – 1000(17B) = – 50 pcs

So, confirmed quantity is zero.

Caution

Supply protection protects related supply protection object total quantity. It defines minimum quantities. So, If every related supply protection objects total quantities can be kept, confirmed quantity is no upper limit until whole inventory consumed.

If you want to set upper limit, use the below “Production Allocation(PAL)”.

Integration into Other Advanced ATP solution

Product Allocation (PAL)

Supply protection and product allocation (PAL) are complementary solutions. While with PAL an upper limit is defined, the logic of supply protection defines minimum quantities.

Backorder Processing(BOP), Alternative Based Confirmation, Allocation Run(ARun)

See: Advanced Available-to-Promise (aATP)

The post Supply Protection of advanced ATP in SAP S/4HANA On Premise appeared first on ERP Q&A.