Background

In SAP S/4HANA Cloud Public Edition, a sales order drives multiple downstream logistics activities automatically. As soon as a sales order is saved, the system confirms available-to-promise (ATP) quantity, transfers requirements to Material Requirements Planning (MRP), and creates purchase requisitions for third-party items. This automatic triggering is efficient for standard order processing — but it creates a challenge when an order requires validation before logistics can proceed.

Below table shows how different blocks control the sales order activities. Some blocks only work in sales document header level. 

Expected Control	Approval Workflow	Delivery Block	Billing Block	Rejection Reason	Incompleteness Status	Credit Block
Stop Order Confirmation (output)	Yes	Yes (HDR)	Yes (HDR)	No	Yes (HDR)	Yes (HDR)
Zero Order Qty Confirmation (ATP)	Yes	Yes (HDR)	N/A	Yes	No	Yes
Stop Transfer of Requirement (ToR)	No	No	N/A	Yes	No	No
Block Delivery Creation	Yes	Yes	N/A	Yes	Yes	Yes
Block Billing Creation	Yes	N/A	Yes	Yes	Yes	Yes
Stop PR Creation	Yes	Yes (HDR)	N/A	Yes	No	Yes

Existing features such as delivery block, credit block, and approval workflow each address part of this challenge. However, they were not designed to provide a unified, item-level mechanism to gate all three logistics activities：

• ATP confirmation,
• Transfer of Requirement (ToR) to MRP,
• Purchase requisition creation

In SAP S/4HANA Cloud Public Edition 2608, a new feature called “Supply Block” is introduced to fill this gap. Supply Block provides control over all three subsequent logistics activities on sales document item level. When a supply block is set to blocked on a sales order item, the confirmed quantity is set to zero, the MRP requirement transfer is stopped, and purchase requisition creation is prevented. When the supply block is cleared, all three activities are immediately revived. See detail of the solution in help document.

In this blog, I will explain how Supply Block works, how it can be configured, and how to implement custom blocking logic using a Cloud BAdI.

Business Example

Supply company XYZ operates a high-volume sales process where orders are entered quickly by the sales team, often before all required information is complete. Logistics activities such as MRP provisioning start immediately upon order save. This means warehouse staff begins allocating stock and planners begin creating procurement proposals or production proposals for orders that may ultimately be cancelled, corrected, or rejected.

Company XYZ wants to implement a process that a sales order must pass a completeness validation before any logistics activity is triggered. An incomplete order — one with missing fields like shipping point, payment terms, or other process critical fields — should have all logistics activities held until the order is corrected and re-saved as complete.

The standard incompletion check exists in SAP, but it does not block ATP confirmed quantity or MRP requirement transfer. The delivery block only prevents delivery creation, not ATP confirmation on item level or MRP requirement transfer.

Company XYZ needs a solution that truly gates all logistics activities at the item level, driven by the order's completeness status.

Solution Overview

The Supply Block feature in SAP S/4HANA Cloud Public Edition 2608 provides the foundation for this requirement. The supply block is set on sales order item level and controls over following subsequent logistics activities:

• Block ATP confirmation (confirmed quantity = 0)
• Block transfer of requirement to MRP
• Block purchase requisition creation

In CE2608, the supply block can be controlled by following:

• via sales document BAdI logic (SD_SLS_FINALIZE)
• via sales order A2X OData API
• by credit check (configuration)
• by approval workflow (configuration)

Please find below diagram for supply block solution overview:

In order to fulfill the requirement from supply company XYZ, we shall perform following steps:

1. Define supply block reason codes for relevant business purpose
2. Enable the supply block for relevant features, e.g. credit management, flexible approval workflow
3. Implement a Cloud BAdI to set or clear the supply block reason automatically based on certain criteria

When the Cloud BAdI detects that a sales order is incomplete, it sets the supply block reason on all relevant items. This immediately stops ATP confirmation, MRP requirement transfer, and purchase requisition creation. When the sales representative corrects the order and re-saves it, the BAdI detects the order is now complete and clears the supply block reason. The system re-runs ATP, revives the MRP requirement, and resumes normal processing.

Step 1: Define Supply Block Reason Codes

There is an SAP pre-delivered supply block reason defined. But it is also possible to define customer specific supply block reason in SSCUI 107392 “Define Supply Block Reason for Sales Document Items”. 

In above screenshot, the supply block reason “01” is predefined value by SAP best practice content. In this example, we will directly use standard supply block reason code “01”.

The supply block reason code is assigned at the sales document item level. When any non-empty reason code is present on an item, the supply block is active for that item. When the reason code is cleared (set to blank), the block is lifted and logistics activities resume.

Step 2: Configure Supply Block Interaction with Credit Block and Approval Workflow

In addition to the direct supply block reason, the Supply Block feature can also be triggered indirectly by two other features:

• Credit management in sales document
• Flexible approval workflow

The supply block can be configured to connect with credit management. You can go to the SSCUI 101518 (Define Automatic Credit Control) to set the supply block relevant to the credit check. See screenshot below. 

When this configuration is enabled, if a sales order is in credit block, all sales order items that is subject to a credit block will also have its supply block status set to “Blocked”. This means that ATP confirmation is suppressed and requirement transfer to MRP is stopped for credit-blocked orders, in addition to the existing delivery hold. 

Approval workflow integration is configured at the level of the approval request reason code. In the SSCUI 102752 (Assign Reasons for Approval Requests), a specific flag “Set Supply Block” can be configured to enable supply block for relevant approval request reason. See screenshot below:

When the supply block is enabled for certain approval request reason, if a sales order in approval workflow with that approval request reason code will also have its supply block status set, stopping requirement transfer to MRP while the order awaits approval.

It is important to understand that credit block and approval workflow affect only the Supply Block Status — a read-only derived field. They do not set the Supply Block Reason on the item. 

Step 3: Implement the Cloud BAdI for Supply Block

The Cloud BAdI SD_SLS_FINALIZE is used to implement custom logic that sets or clears the supply block reason during the sales order finalize phase. This is the point in the order processing flow where all order data is consistent and complete, making it the most reliable place to evaluate completeness and apply the block.

The BAdI receives the full sales document context including relevant incompletion status fields. In the BAdI implementation, we check whether all relevant incompletion statuses indicate that the order is complete.

SAP provides several status fields that reflect different aspects of order completeness on document level and item level:

• general incompletion,
• billing incompletion,
• pricing incompletion,
• delivery incompletion,
• etc.

Only when all of these statuses show `C` (complete) does the BAdI allow logistics activities to proceed.

Implement the following logic in the BAdI:

IF salesdocument-soldtoparty = ‘XXX'.
DATA(lv_block) = abap_false.

” Check all incompletion statuses — ‘C' means complete
IF salesdocument-ovrlitmgeneralincompletionsts=”C” AND
salesdocument-hdrgeneralincompletionstatus=”C” AND
salesdocument-headerbillgincompletionstatus=”C” AND
salesdocument-overallpricingincompletionsts=”C” AND
salesdocument-headerdelivincompletionstatus=”C” AND
salesdocument-ovrlitmbillingincompletionsts=”C” AND
salesdocument-ovrlitmdelivincompletionsts=”C”.
lv_block = abap_false.
ELSE.
lv_block = abap_true.
ENDIF.

LOOP AT salesdocumentitems_change ASSIGNING FIELD-SYMBOL(<ls_item_change>).
IF lv_block IS NOT INITIAL.
<ls_item_change>-salesdocitemsupplyblockreason = '01'.
ENDIF.
<ls_item_change>-control-salesdocitemsupplyblockreason = ‘X'.
ENDLOOP.
ENDIF.

There are two key implementation details to note:

1. First, the ‘control-salesdocitemsupplyblockreason' field must be set to ‘X' for every item in the change collection, even when clearing the block. This signals the framework to process the change, without it, the updated reason code value will be ignored.
2. Second, when clearing the block, the supply block reason field is simply left empty (not explicitly set to blank); the framework handles the clearing automatically when the control flag is set.

Checking Supply Block Status in the Fiori UI

The sales representatives can search and display the supply block status directly in the Fiori app “Manage Sales Orders – version 2” and app “Manage Sales Documents”.

The supply block reason and relevant status fields are also available in the sales order Fiori app. See below screenshot of showing overall supply block status in document header level.

Below screenshot shows the supply block reason and relevant status on item level.

Business Process Testing

Test Case 1: Incomplete sales order — supply block is set automatically

Create a new sales order for company XYZ with an incomplete item — for example, leave the shipping point empty on one item. Save the order. The BAdI detects that the incompletion status on this item is not complete and sets supply block reason “01” on this item.

But for item 10 and item 20, there is no supply block set. Therefore, the confirmed quantity is not zero and the requirement is transferred to MRP. Let's check them one by one. 

For item 10, the availability check confirmed the quantity, and the requirement is also visible in the MRP. See below screenshot for ATP confirmed quantity of item 10.

Below screenshot proves that the requirement of sales order item 10 is transferred to MRP.

For item 20, because it is the 3rd party product, the purchase requisition is generated. See screenshot below.

Test Case 2: Order completed — supply block is cleared automatically

Open the sales order and update the incomplete sales order by providing the missing shipping point.

Save the sales order. The BAdI now checks all incompletion statuses and leaves the supply block reason empty for item 30.

The system immediately re-runs ATP, the confirmed quantity is restored to the requested quantity, and the requirement of sales order item 30 is transferred to MRP, see screenshot below.

Conclusion

Supply Block in SAP S/4HANA Cloud Public Edition 2608 gives companies a powerful, item-level mechanism to control downstream logistics activities during sales order processing. 

By combining Supply Block with the Cloud BAdI “SD_SLS_FINALIZE”, it is possible to implement a low-risk process that gates ATP confirmation, MRP requirement transfer, and purchase requisition creation until a sales order passes a completeness validation.

The Supply Block feature also integrates naturally with credit block and approval workflow, allowing companies to extend their existing validation processes to cover logistics activities. Unfortunately this part is not demonstrated in this blog. Please stay tuned for more blogs of supply block. 

This approach demonstrates the flexibility of SAP S/4HANA Cloud Public Edition's extensibility framework — a standard feature combined with a Cloud BAdI can deliver sophisticated, customer-specific validation logic while staying fully within the upgrade-safe extensibility model.

Please find other BAdI use cases in the blog Sales Document BAdI Overview, and feel free to submit your requirements through the Customer Influence Portal to help us prioritize our product roadmap.

Source link