In the Global Available-to-Promise (Global ATP) module, it is not possible to change configuration objects like scope of check and check instructions based on parameters such as sales order type, delivery priority, or customer group. That inability restricts you from dynamically changing the consideration of various supply types (for example, different stock types, production orders, and purchase orders) during the sales order confirmation process. This might result in suboptimal allocation of the available supply to customer orders. By doing enhancements during an ATP check at the time of order entry in SAP ERP Central Component (ECC) as well as during the backorder processing (BOP) run in SAP Advanced Planning and Optimization (SAP APO), it is possible to consider the various parameters mentioned above while deciding how the supply is allocated to different customer orders.

There are various business scenarios and requirements in which it is important to have flexibility in the way the supply is allocated to customer orders.

• For critical orders such as rush orders, it is important to make sure confirmation is made only against truly available stock. Stock under quality inspection should not be used to provide confirmation as it might result in disappointing the customer since the rush order is confirmed but can’t be shipped as the stock is still under inspection. However, the quality inspection stock can still be used to provide confirmations to regular sales orders since the delivery dates on the regular sales orders are at least two to three days in the future. By that time the stock can be inspected and made available to be shipped.
• There are certain really high priority orders for which it is acceptable to push other regular sales orders to future dates. In such cases, the requirement would be to provide confirmation based on available on-hand stock considering any open deliveries. This would make sure that there is no manual step involved in removing a confirmation from an existing confirmed sales order and that the high priority orders are shipped as soon as possible. The nightly BOP run would take care of adjusting the dates in the sales orders.
• In the semiconductor industry, the finished goods are packaged in a particular lot size (tape and reel) and customers typically place orders in multiples of that lot size. However, due to the inherent variability of the manufacturing process, the output is not always in that multiple and the remainder quantity (called broken reels) is stored separately. This can’t be used to fulfill regular customer orders but can still be used for special orders such as customer samples. In such cases, the requirement is that the customer samples orders should only see this stock for confirmation and all other orders should see it as available.
• Another scenario is that if the sample order is critical and there are no broken reels available, existing reels are then broken to fulfill the customer sample orders. In such cases, the requirement would be to enable such critical sample orders (identified by some parameters on sales order such as delivery priority) to receive confirmation based on the regular supply instead of considering only the broken reels stock.
• Location substitution is enabled as a normal process for all the customers but in some exceptional conditions a customer may not want to have the ordering plant changed and would like to have its entire order shipped together and from a single plant. Also it may not make sense to move inventory from one plant to other just for fulfilling those particular orders. Such exception orders can be identified by some parameters in the sales order and the requirement would be not to trigger the location substitution rules in such cases.
• In order to control the supply allocation, product allocation functionality is enabled, which controls how much quantity can be allocated to a particular customer in a given time period. However, sometimes it is important to have flexibility: Even though the allocated quantity is already consumed, the customer order should still receive a confirmation overriding customer allocations.
• Checking horizon (which determines how far in the future product availability is checked) is used while confirming the sales orders, which ensures that if there is no available supply then the order is confirmed at the end of the lead time. There might be cases in which checking the horizon is not required for most customer orders but is required only for certain specific cases. Or it could be reversed, with it enabled for most customers but not enabled for certain customers or order types.

ATP Configuration Objects in SAP APO

Let’s review the key configuration objects available within SAP APO and what role they play during the sales order confirmation process. Figure 1 summarizes each configuration object and how they are linked to each other.

Figure 1

ATP configuration objects

The diagram in Figure 1 helps you understand which objects need to be tweaked so that you can get the desired control and flexibility during the ATP check.

1. Check mode defines the requirement type or strategy type and is determined in ECC based on the item category of the order. It can also be derived from the strategy type in the product master. To navigate to view the check mode, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Check Mode.

Figure 2 shows various predelivered check modes available in SAP APO.

Figure 2

The Check Mode screen

With the check mode, you can control the following:

• Assignment mode determines how a sales order consumes the forecast. Typically, this would be configured in ECC for each sales order type (with a corresponding requirement type) and there would not be any need to tweak it for exception conditions. However, if there is a requirement not to allow forecast consumption for certain specific orders meeting exception conditions, then the check mode needs to be changed to another check mode for which the assignment mode is set to No Assignment, which prevents forecast consumption.
• Production Type controls how the system executes the ATP check. The key control available here is the ability to decide if the system should do a multi-level ATP check and check the availability of components, do a Capable-to-Promise (CTP) check, or just check at the finished good level without triggering any production in the system.
• Rounding Procedure controls if the ATP check results use rounding requirements or not.

2. Business event is an indicator that helps to differentiate between various ECC documents such as sales orders, deliveries, and stock transfer orders. There are standard business events that are triggered depending on the type of document. For example, business event A is triggered for sales orders, B for deliveries, and PP for production orders. It is also possible to create custom business events and then use them in combination with the check mode or ATP groups to get the desired control and flexibility during the ATP check.

To navigate to view the business event, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Business Event. Figure 3 shows various predelivered business events available in SAP APO.

Figure 3

Business events

• Basic availability checks: Here you can maintain which basic availability check methods should be used and in what sequence they should be used during the ATP check. Typically, if product allocation is used, then the first step is always the product availability check so that there is consistency in the buckets from which the supply is confirmed and product allocation is consumed. This gives you control if you want to turn on or off a product allocation based on business requirements. To navigate to view the check instructions follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Check Instructions. Figure 4 shows various predelivered check instructions available in SAP APO and highlights the fields relevant for basic availability checks.

Figure 4

Check instructions with basic ATP methods

• Rules-based ATP check: This is where you control if the rules-based ATP check should be activated or not and if it should be executed prior to the product availability check or later. Figure 5 highlights the fields relevant for a rules-based ATP check for the various check instructions.

Figure 5

Check instructions for a rules-based ATP check

• Production: In this section, you can configure if production should be triggered during the ATP check. The mode of production could be a Multi-Level ATP check or CTP depending on the option selected in the Check Mode. Figure 6 highlights the fields relevant for production for the various check instructions.

Figure 6

Check instructions for production

• Cumulation defines whether requirement quantities or confirmed quantities are cumulated during the ATP check at the time of sales order creation and sales order changes.
• Bucket logic defines how ATP time series are evaluated during the product availability check.

Typically, there are no business requirements whereby the ATP group needs to be changed for a particular customer or order type or any other parameter since the ATP group controls cumulation of the quantities and bucket logic, which are never required to be varied based on these parameters. To navigate to view the check instructions, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise >Product Availability Check > Maintain ATP Group. Figure 7 shows various predelivered ATP groups available in SAP APO and highlights the fields relevant for basic availability checks.

Figure 7

ATP group

• General: To navigate to view the check control, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > Product Availability Check > Maintain Check Control. In this section, the key control available to you is the setting for considering checking the horizon during the ATP check. Figure 8 shows various check controls that come predelivered in SAP APO and also highlights three options available for setting the checking horizon. There could be valid business requirements for this to be varied for different customers, order types, or delivery priorities for different orders of the same product.

Figure 8

The General section for the scope of the check control

• Scope of check: This section is the most important one since this is where you get the control to consider various demand-and-supply elements during the ATP check. To navigate to this section, highlight a row that has the ATP group and business event and double-click ATP Check Control: Scope of Check as shown in Figure 9.

Figure 9

Scope of the check in ATP Check Control

This action takes you to the next screen shown in Figure 10 that shows various ATP categories for demand, supply, and stock for a given ATP group and business event.

Figure 10

ATP categories

As explained above, check instructions and check control are the key configuration objects, but you have limited flexibility while defining them. Check instructions are based on a combination of check mode, which is derived either based on a strategy group in the product master or based on the requirement type in the sales order. Business events are fixed based on various document types. If you need to control triggering of product allocation, rules-based ATP, multi-level ATP, or CTP at a detailed level such as product and customer or product, customer, and order type on an exception basis, it is not possible to achieve it in the standard SAP system.

A similar issue exists with check control since it is a combination of an ATP group (defined at the product level) and business event (predefined for each document type). So if you want to vary demand and supply elements that should be considered during an ATP check based on product and customer or any detailed level beyond product, you can’t do it in standard SAP.

With the proposed enhancements and configuration, the possibilities are endless, and it is possible to be as detailed as required with the caveat that the requirements are validated and thorough testing is done to make sure the results are always consistent.

The next section describes the configuration required in APO and enhancements needed in ECC and APO to overcome the issues described above.

To decide what needs to be configured, you should first list all the scenarios and requirements for which the ATP check needs to vary. Based on that, you can decide how many new business events are required so that you can have different check instructions and check controls.

Business Event: To create a new business event, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Business Event and click the New Entries button as shown in Figure 11.

Figure 11

Maintain a business event

Enter the business event and description as shown in Figure 12.

Figure 12

Enter the new business event

I have configured four new business events for each of the scenarios for which I have different ATP check requirements as shown in Figure 13.

Figure 13

Custom business events

Check mode: You don’t need to create a new check mode unless there is some very specific requirement related to production or rounding. Check mode also controls forecast consumption. If the new check mode has a different forecast consumption setting, then it is considered only when the check mode is changed when the sales order is transferred from ECC to APO. User exit EXIT_/SAPAPO/SAPLCIF_SLS_001 can be implemented in APO to change the check mode on an exception basis (based on parameters such as delivery priority or customer group) so that certain orders don’t consume the forecast. I don’t go into more detail since it is beyond the scope of this article. However, in general, you can assume that there is no need to change the check mode during an ATP check.

Check instructions: You can configure new check instructions for the combination of the check mode and the newly created business events. They would be configured in such a way that the key settings are different and meet the business requirements.

To create a new check instruction, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Check Instructions and click the New Entries button s highlighted in Figure 14.

Figure 14

Maintain a new check instruction

Let’s create two check instructions, one with check mode ZMA and business event A and another with check mode ZMA and newly created business event ZA. Figure 15 shows the new check instruction for check mode ZMA and business event A in which the product allocation check is enabled since we are calling it in the second step after the product check.

Figure 15

Product allocation enabled

Figure 16 shows the new check instruction for check mode ZMA and business event ZA in which product the allocation check is not enabled but the product check is.

Figure 16

Product allocation override

Let’s consider a scenario in which as a standard process a product allocation check is needed to be performed before confirming orders to customers. In this case, the check instruction configured for check mode ZMA and business event A would be relevant as shown in Figure 14.

In case there is a need to override the product allocations and confirm certain customer orders without looking at the allocation, then the check instruction configured for check mode ZMA and business event ZA needs to be considered during the ATP check.

Similarly, you can create new check instructions for a given check mode and corresponding new business event if you want to enable or disable rules-based ATP, multi-level ATP checks, or CTP checks.

ATP group: There is no need to create a new ATP group since there are no valid business requirements to change cumulation or bucket logic on an exception basis.

Check control: Similar to check instructions, you can create a new check control for a given ATP group and new business event so that you can control the ATP check for specific business requirements.

To create a new check instruction, follow customizing menu path SPRO > Advanced Planning and Optimization > Global Available to Promise > General Settings > Maintain Check Instructions and click the New Entries button as highlighted in Figure 17.

Figure 17

Create a new check control

Let’s create two check controls, one with ATP group Z1 and business event A and another with ATP group Z1 and business event Z1. Figure 18 shows the new check control for check mode Z1 and business event A where there is no confirmation at the end of the checking horizon.

Figure 18

No checking horizon

Figure 19 shows the new check control for check mode Z1 and business event ZI where there is confirmation at the end of the checking horizon.

Figure 19

Check control — Confirmation at Checking Horizon

Let’s consider a scenario in which as a regular process there is no confirmation at the end of the checking horizon. That means that if there is insufficient supply available, an order would remain unconfirmed or partially confirmed until the supply situation improves. So for the regular process, you would use the check control similar to what was created for ATP group Z1 and business event A as seen in Figure 18.

However, for certain customers, unconfirmed or partially confirmed orders might not be acceptable and it may not be practical to wait for the next planning run to improve the supply situation and get the confirmation dates in the sales order. In such cases, you would use the check control similar to what was created for ATP group Z1 and business event ZI as shown in Figure 19.

You can exclude or include certain demand or supply elements during the ATP check in the Scope of Check section of the check control. Figure 20 shows a check control that was created for rush orders and inspection stock is not included in the ATP check.

Figure 20

Check control for rush orders excludes inspection stock

For the sake of consistency, any new business event, check control, and check instructions created in APO should also be created in ECC, although it is not required.

Enhancement Required in ECC

Once the business requirements are clear and the corresponding configuration (as explained in the previous section) is done in APO, you need to do an enhancement during the sales order ATP check in ECC so that you can change the business event or check mode as and when required. 

For this, you need to implement user exit EXIT_SAPLATPC_001, which is called before the ATP check is triggered in APO from ECC during sales order creation or change. As seen in the Figure 21, in this user exit, there is a structure, T_ATPCSX, in which you can change the business event or check mode as per the business requirement.

Figure 21

Sales order ATP user exit

The field name for the business event is PRREG and for the check mode it is CHMOD.  The pseudocode for changing the business event for a rush order is as shown in Figure 22.

Figure 22

Pseudocode for a rush order

The coding required would be pretty much similar for most of the cases except for determining the exception condition as highlighted in red in Figure 20. In the above example, the exception condition was the order type, but it could be any attribute or parameter in the sales order such as customer number (sold-to/ship-to), customer group, or delivery priority. 

Enhancement Required in APO

If BOP is used in APO to realign the supply with the sales orders, then a similar enhancement is required in APO as well.

In APO, the user exit that needs to be implemented to change the business event or check mode is EXIT_/SAPAPO/SAPLBOP_040, which is called during BOP run. In this user exit, implement the same logic that was implanted in ECC so that the BOP results are consistent with the ATP results during sales order creation or changes in ECC.

As highlighted in Figure 23, the key tables that need to be updated in this user exit are CT_REQ and CT_HOWTOCHK. Most of the sales order-related data is available via function module /SAPAPO/ATP_SD_ORDER_GET.

Figure 23

BOP user exit in APO

Once the data is extracted, update the fields PRREG and CHMOD in tables CT_REQ and CT_HOWTOCHK. The link to CT_REQ and CT_HOWTOCHK tables is the field REQIDX.  The pseudocode for changing the business event for a rush order is shown in Figure 24.

Figure 24

Pseudocode in APO

Apart from this user exit, other user exits might be required depending on the business requirement. For example, if a particular order type needs to be excluded from the scope of the check, then you need to change the ATP category of that sales order so that it is separated from other sales orders. This can be done by implementing user exit EXIT_/SAPAPO/SAPLCIF_SLS_001. As seen in Figure 25, IT_SL_REQ and IT_SL_DOC are the key tables in this user exit. The ATP category can be changed in table IT_SL_REQ and the order type is available in table IT_SL_DOC.

Figure 25

Sales order user exit

Similarly, if the stock from a particular storage location needs to be excluded for certain orders, then the ATP category for that stock can be changed in user exit EXIT_/SAPAPO/SAPLCIF_STOCK_001 and that ATP category can be excluded from the scope of check. Figure 26 highlights the table IT_STOCK in this user exit. It contains the field ATPCAT, which can be changed based on the field STORAGELOC.

Figure 26

Stock user exit in APO

I will not discuss it further since it is beyond the scope of this article.

Once the above configuration and enhancements are done, you can control the ATP check as per your business requirements. In the last section, I briefly describe what needs to be done to meet the requirements of some of the business scenarios I listed earlier in this article.

Use Cases for Leveraging the Proposed Enhancements

I now describe four use cases for leveraging the proposed enhancements:

1. Exclude inspection stock for rush orders: The configuration and enhancement for the excluding inspection stock for rush orders is already explained in the above sections. You need to change the ATP category from A to Z1 (or any custom value) if the order type is rush. This ensures that the appropriate scope of check is triggered for this particular Z1 business event and ATP group, which doesn’t include inspection stock (ATP category CD).
2. High-priority orders: In this scenario, you want high priority orders to be shipped as soon as possible. They have the highest priority, which means it is acceptable to pull supply from some other less important orders. Therefore, you can change the business event to B, which is normally triggered during delivery creation. The scope of the check that is triggered would only consider the stock on hand as supply and open deliveries and reservations as demand.
3. Sample orders in the semiconductor industry: Here the requirement is to fulfill the sample orders only from the broken reel stock, which is kept in a separate storage location. On changing the delivery priority, you fulfill from the regular supply pool. In this case, you would first change the ATP categories for the sample order and broken reel stock to custom ATP categories so that they can be identified separately from the regular sales orders and stock respectively. A new business event replaces the standard business event A whenever the order type is SAMPLE ORDER. This ensures that the appropriate scope of check is triggered. It would only have the sample orders (which are in custom ATP category) as the demand element and broken reel stock (custom ATP category) as the supply element. If there is no stock available under broken reel stock, then the user can change the delivery priority to a particular value that can be used to change the business event back to A. Then the regular scope of check can be triggered, which would follow the standard process.
4. Override product allocation: In this scenario, the requirement is to allow an order to be confirmed even if there is no allocation available for that customer in that particular time period. One of the ways to achieve this would be to change the business event to a new custom business event during sales order creation and BOP run so that it triggers the check instructions that don’t have the product allocation check as one of the ATP methods. This way the order would be confirmed as long as there is supply available.

The scenarios described above leverage some of the enhancements available within SAP ECC and APO to meet the business requirements. There are a few other user exits and Business Add-Ins (BAdI) available within SAP APO that can also be used to meet any other requirements not addressed by Global ATP. Table 1 lists some of the user exits, their descriptions, and scenarios in which they can be used.

Mitesh Verma

Mitesh Verma has 14 years of experience in supply chain consulting, SAP APO implementation, and enhancements. He is an SAP SCM solution architect at Dorman Products specializing in multiple modules (DP, SNP, GATP, and PP-DS) of SAP APO. He has worked on supply chain projects for various clients in the high-tech, semiconductor, automotive, and food and beverage industries. 

You may contact the author at mitesh.verma@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.