Implementing SAP Advanced Planning & Optimization (SAP APO) Global Available-To-Promise (Global ATP) can have a significant impact on the entire order fulfillment process cycle, including order entry, pricing, shipping, and billing. An understanding of the process and technical aspects of integration is crucial for an effective and smooth implementation.

In the first part of this series, we provided a high-level overview of Global ATP functionality and how it helps organizations improve their order fulfillment processes. In the second part we discuss integration aspects that take two forms — process and system. We discuss the business process impact of Global ATP in areas such as pricing and shipping as well as the technical configuration or master data required for integration. We provide information that helps project teams planning on implementing Global ATP with SAP ERP Central Component (SAP ECC) as the order entry and execution system.

• Key configuration steps that should be taken into account in SAP ECC and SAP SCM and their interaction
• Master data integration between SAP ECC and SAP SCM
• Specific functionalities in SAP SCM (such as rules-based ATP) and what should be considered when implementing these functionalities
• Customizing in SAP ECC and SAP SCM and leading practices for transporting customizing from system to system
• Recommendations and points to consider for Global ATP check by document type (such as sales orders and stock transport orders)

The order of the concepts discussed in this article closely follows the order that you may want to consider in an actual implementation (although the concepts and topics that we cover should not be deemed a step-by-step cookbook).

Set Up Connectivity for the Global ATP Check

The Global ATP check is a synchronous remote function call (RFC). It is unlike most other core interface (CIF) communication between SAP ECC and SAP SCM that uses asynchronous RFCs. SAP recommends that a separate RFC destination to SAP SCM be defined in SAP ECC for the Global ATP check. This RFC destination is assigned to application AC (for availability check) in transaction CFC7 in the SAP ECC system (Figure 1). Follow menu path SAP Customizing Implementation Guide > Integration with Other mySAP.com Components > Advanced Planning and Optimization > Basic Settings for Setting Up the System Landscape > Assign RFC Destinations to Different Application Cases.

Figure 1

Assign the CIF application to the RFC destination

The Global ATP check needs an RFC connection with a dialog or service user type to perform the check. Because a dialog user within RFC connections is a potential security loophole, we recommend that the RFC user have limited access. Refer to user roles listed in the SAP SCM Security Guide under https://service.sap.com/securityguide > SAP Supply Chain Management > SAP Supply Chain Management Security Guide; (“Authorizations” section) > Maintaining Authorizations for the Integration with SAP Components > Maintaining Authorizations for Available to Promise (ATP). If you do not limit the authorization of this dialog or service user, theoretically, a user can perform an ATP check and can then potentially access other SAP SCM system transactions from the results screen.

Basic Configuration in SAP SCM

When you are setting up a new SAP SCM system for Global ATP, the basic configuration is similar to those for other SAP SCM modules. These include:

• Set up SAP ECC as a source system in the SAP SCM system — Business Information Warehouse (SAP NetWeaver BW) in transaction RSA1.

• Replicate units of measure and factory calendars (Transfer Global Settings) using program RSIMPCUST in the SAP SCM system.

• Maintain countries, country-specific checks, regions, and transportation groups in SAP SCM. This task may be required in some cases either because SAP-delivered content may be slightly different in the SAP ECC and SAP SCM systems or because new configuration was maintained in SAP ECC.

To avoid CIF errors (especially during back-order processing), it can be a good idea to compare relevant basic configuration tables between SAP SCM and SAP ECC. Consider using transactions SCU0 (Customizing Cross System Viewer) or transaction /SAPAPO/CHECK_CUST in the SAP SCM system for comparison.

To help minimize issues during transportation and delivery scheduling, consider using the same time zone setting (transaction STZAC) between SAP SCM and SAP ECC systems. Using reports TZCUSTDISP and TZCUSTHELP, confirm (for each application server in SAP ECC and SAP SCM) that time definitions are consistent. Refer to SAP Note 481835 for details on analyzing time zone settings. Use report TZONECHECK to check time zone data for consistency.

When you are creating time stream calendars for use in configurable process scheduling in SAP SCM, we suggest that you assign time zones. Otherwise, the system assumes the time zone is coordinated universal time (UTC) for the related activity, which can cause inconsistent scheduling results.

Model and Version

Global ATP uses the active model and version 000 only. Unlike other SAP APO modules, simulation versions are not relevant. If you want to use the Product Availability basic check in Global ATP, take this step. Before you transfer transaction data to SAP SCM through the CIF, confirm that the Update from ATP Time Series option is checked for the Planning Version 000 in transaction /SAPAPO/MVM in the SAP SCM system (Figure 2). (Availability check is one of three basic checks in Global ATP along with the allocation check and the forecast check).

With this flag activated, demand and supply are redundantly stored in the form of an ATP time series in Livecache. To help improve performance, Global ATP uses this ATP time series to perform the availability check instead of calculating availability based on individual orders in the order-based Livecache.

Figure 2

ATP setting for Model & Planning Version 000

The Update from the ATP Time Series check box is not editable in an active system (i.e., with existing transaction data). If you already use other modules of SAP SCM prior to implementing Global ATP, refer to SAP Note 792286 (SAP SCM 4.1 and higher) to activate the ATP time series.

Set Up the CIF for the Global ATP Check

Global ATP requires material and plant master data to be transferred using the CIF (transaction CFM1 in SAP ECC) from SAP ECC to SAP SCM. The ATP check integration model (that is set up for a plant and material combination) determines if an ATP check occurs in SAP ECC or in SAP SCM (Global ATP) (Figure 3).

Figure 3

ATP check CIF integration model

Note that the ATP Check indicator does not determine whether the ATP check is carried out. That is determined based on a standard SAP ECC availability check configuration (at the requirements class level, for example).

Note that the following processes that are performed in SAP SCM trigger a Global ATP check in SAP SCM and therefore disregard the settings of the ATP Check CIF integration model (that is, these processes disregard the settings made in SAP ECC integration models):

• Back-order processing (including back-order-related processes such as Event Driven Quantity Assignment [EDQA])
• Conversion of planned orders
• ATP check of Multi-Level ATP (MATP) — Check of components
• ATP check of Rules Based ATP — Check of substitute product/ locations

This is because CIF integration models determine selection criteria for the flow of data from SAP ECC to SAP SCM, but not the other way around. Refer to SAP Note 1172687 for further details.

Determine transaction data requirements in SAP SCM based on the documents for which the availability check is carried out in SAP SCM and the scope of the check for each of these availability checks. (The scope of the check determines the supply and demand elements considered during the availability check.) For example, if you perform a Global ATP check for sales orders, you should transfer sales orders to SAP SCM through the CIF, but you also should transfer stock, purchase orders, and production orders if they are in the scope of the check during the Global ATP check of sales orders (either as demand elements or receipt elements). 

Global ATP requires real-time data in SAP SCM to provide realistic commits. CIF issues, such as blocked queues, result in an inaccurate snapshot of demand and supply during the Global ATP check. Consider running CIF monitoring frequently (reports /SAPAPO/RCIFINQUEUECHECK and /SAPAPO/RCIFQUEUECHECK) to inform system administrators if queues are blocked. Run the Comparison/Reconciliation report (transaction /SAPAPO/CCR) frequently (e.g., daily) in SAP SCM to maintain consistency of transaction data between SAP ECC and SAP SCM. Typically, this may be done before a back-order processing run so that the newly calculated ATP dates or quantities are based on consistent data.

ATP Customizing

Generate and activate an integration model for ATP customizing. This step brings basic ATP settings (such as checking groups and check control) to SAP SCM. This CIF integration deletes existing table entries in SAP SCM before adding values from SAP ECC. Therefore, we recommend that this step be done only once at the time of implementation.

Post-implementation changes in SAP ECC to ATP customizing should be replicated manually in SAP SCM. Post-implementation, set the Import Customizing field to Not allowed in SAP SCM using transaction /SAPAPO/ATPC00 (Figure 4) to prevent inadvertent loss of related configuration changes that may have been made directly in SAP SCM.

Figure 4

ATP global settings

Table 1 shows the customizing objects created in SAP SCM and their SAP ECC mapping.

Table 1

Global ATP customizing objects and SAP ECC mapping

Transferring ATP customizing through the CIF from SAP ECC to SAP SCM deletes and re-creates customizing tables in SAP SCM. Therefore, we suggest you consider using the sequence of transports/CIF in a multisystem landscape (e.g., development, quality, production) that we found to be effective (Figure 5).

Figure 5

Sequence of transports/CIF in a multisystem landscape for Global ATP customizing

1. Maintain ATP customizing in SAP ECC development (optional — if delivered content is not sufficient)

2. CIF ATP customizing from SAP ECC development to SAP SCM development. Add customizing in SAP SCM development (optional — SAP SCM-specific customizing, if any)

3. Transport ATP customizing from SAP ECC development to SAP ECC quality. CIF ATP customizing from SAP ECC quality to SAP SCM quality.

4. Transport Global ATP customizing from SAP SCM development to SAP SCM quality.

5/6/7. Steps 5, 6 and 7 are a repeat of the preceding four steps for production or other environments.

Master Data Integration

After the locations masters are transferred from SAP ECC to SAP SCM through the CIF, you should create time-stream calendars using transaction /SAPAPO/CALENDAR. You then assign them as receiving and shipping calendars to locations in SAP SCM (Figure 6) using transaction /SAPAPO/LOC3.

Figure 6

Assign time-stream calendars to locations

Receiving calendars are used to find purchase order availability dates based on goods receipt processing time. Shipping calendars are required to be assigned to locations if you use rule-based ATP even if you set up condition records calendar determination using configurable process scheduling. This is because Global ATP uses these shipping calendars for determining product-location validities during rule evaluation.

If you use product interchangeability, time-stream calendars (both for shipping and receiving calendars) assigned to locations should be extended for the time horizon over which product interchangeability is defined (valid-from and use-up dates). Otherwise, the scheduling results may be unpredictable.

Handling resources should be defined using transaction /SAPAPO/RES01. You can then assign them to location masters in SAP SCM using transaction /SAPAPO/LOC3 if you need to integrate production orders from SAP ECC. That is, if production orders are considered as supply in your scope of check.

The material master CIF populates the ATP Group, Check Mode, Checking Horizon, Checking Horizon Calendar, and Allocation Procedure in the ATP tab of the location product (Figure 7).

Figure 7

ATP tab in the SAP SCM product master

Table 2 lists some of the important SAP SCM product master fields and their mapping to SAP ECC objects.

Table 2

SAP SCM product master ATP fields and their SAP ECC mapping

Note that for sales orders, the check mode (requirements class) is determined dynamically based on requirement type determination configuration maintained in transaction OVZI in SAP ECC (Figure 8). Some of the most common ATP logical errors occur because of incorrect assignment of check mode. If, for example, you find that the system is not triggering rules-based ATP, the first thing to check is the requirements class determination in SAP ECC (and from this, the check mode).

Figure 8

Requirement type/class determination

For all Global ATP checks other than sales orders (for example, stock transport orders), the system uses the check mode that is assigned to the SAP SCM product master. This procedure also applies in a sales order rules-based ATP check for the subsequent requirements (substitutions).

Allocation Planning

Global ATP’s product allocation functionality is often used in constrained supply scenarios. Product allocation quantities are maintained in a DP planning area. While you are configuring Product Allocation Groups in SAP SCM (transaction /SAPAPO/ATPCQ_GRP), there are two options to check the product allocation quantities (Figure 9):

• The data that is maintained in the DP planning area can be transferred to the Global ATP product allocation group (and therefore, the allocation check happens against the product allocation group within Global ATP).
• The allocation check can be done directly in the DP planning area (if the Check Planning Area setting is checked in the definition of the Product Allocation Group). Figure 9 has the Check planning area indicator selected.

Figure 9

Connect the DP planning area to the product allocation group

It might appear that the second option is better because there is no data transfer between the DP planning area and the product allocation group. However, note that if a user modifies the allocation quantities in the DP planning book, sales orders cannot be taken for the same characteristic combinations because of locking. Depending on order volumes, the first option — the check against the product allocation group — might be better.

Rules-Based ATP

Rules-based ATP can result in the creation of one or more sub-items on the sales order (typically if there is a product or location substitution). This can affect the following –

• Pricing: Determine if pricing should be based on the main item or sub-items depending on the item category. There could be potential pricing issues in some situations when rules-based ATP is used. For example, consider the following situation: A customer orders item A, but is actually fulfilled with item B (a substitute) based on availability. Whether the customer should be charged the price for item A or the price for item B is a business decision, and the system should be configured accordingly.
• Delivery: Determine if the main item or sub-items are delivery relevant based on the item category.

Most fields in the sub-item are not editable on the sales order. For example, shipping points, routes, delivery priorities, and sales texts cannot be edited on sub-items. These fields are either copied from the main item or identified using determination rules in SAP ECC.

Consider how you want to handle the remaining requirements in the Maintain Check Instructions screen in SAP SCM (transaction /SAPAPO/ATPC07) (Figure 10). If you choose not to create the remaining requirements, the total order line price is not based on requested quantities and is instead based on confirmed quantities.

Figure 10

Set up remaining requirements in the Maintain Check Instructions screen

You can control the rules accessed in rules-based ATP at an order type level using business transactions that you define in the sales order type configuration in SAP ECC. The menu path for defining a business transaction setting is SAP IMG > Sales & Distribution > Basic Functions > Availability Check > Rule-based Availability Check > Define Business Transaction (Figure 11).

Figure 11

Set up business transactions

Assign the business transactions to sales order types using menu path SAP IMG > Sales & Distribution > Basic Functions > Availability Check > Rule-based Availability Check > Assign Business Transaction to Sales Order Type (Figure 12).

Figure 12

Assign business transactions to sales order types

In Global ATP, you can then use these business transactions for determining rule strategies by following menu path mySAP SCM – IMG > Advanced Planning and Optimization > Global Available-to-Promise > Rules-Based Availability Check > Assign Rule Strategy or Rule Strategy Sequence (Figure 13).

Figure 13

Assign rule strategies or rule strategy sequences

Don’t confuse the two similar sounding terms business transactions and business events. Business transactions are used only to modify system behavior by order type in rules-based ATP, whereas business events define the scope of the check and check instructions.

SAP delivered content includes configuration for the TAPA (main item) and TAN (sub-item) item category determination (transaction VOV4 in SAP ECC) (Figure 14). If you are using custom item categories in SAP ECC, set up similar configuration as TAPA/TAN. Also, refer to SAP Notes 505086 and 150139 because you should set up similar relationships that exist between TAPA and TAN in the item category configuration.

Figure 14

Item category determination

For existing sales orders with sub-items, when an ATP check is triggered in transaction VA02 (or during a back-order processing update), the system tries to delete and recreate sub-items. This is true even if you run back-order processing without rule evaluation. This implies that any changes made at the sub-item level (including manually maintained text) are lost. Also, if the sub-item is referenced on another document (because it was used as a reference when creating the other order such as a return order), then the system cannot delete the item and instead tries to reject it with reason code 00.

Stock Transport Orders

From a Global ATP perspective, both of the following configuration steps are required in SAP ECC to avoid CIF errors during back-order processing of stock transport orders. (They are not required if SAP Note 1279677 is implemented.)  

1. Maintain configuration for Assigning Document Types to Stock Transport Orders using menu path SAP Customizing Implementation Guide > Materials Management > Purchase Order > Setup Stock Transport Order > Assign Document Type, One-Step Procedure Under-delivery Tolerance (Figure 15).

Figure 15

Document types for stock transport orders

2. Maintain configuration to assign default Purchasing Organization to Plants using menu path SAP Customizing Implementation Guide > Enterprise Structure > Assignment > Materials Management > Assign standard purchasing organization to plant (Figure 16).

Figure 16

Default purchasing organization for the plant

When you transfer stock transport orders to the target system, the target system reschedules them. The target system can be SAP ECC when the stock transport order is being sent to SAP ECC, and it is SAP SCM when changes are made to stock transport orders and updated in SAP SCM. This can lead to a mismatch of dates or times in the two systems.

You can suppress rescheduling of a stock transport order sent from SAP ECC to SAP SCM through the CIF using transaction CIFPUCUST02 in SAP ECC (Figure 17). Similarly, you can suppress rescheduling of stock transport orders sent from SAP SCM to SAP ECC (after back-order processing) through the CIF with transaction /SAPAPO/CIFPUCUST02 in SAP SCM (Figure 18). SAP Note 1287148 describes configuration and master data related to time zones necessary for these settings to work.

Figure 17

Suppress rescheduling in SAP SCM

Figure 18

Suppress rescheduling in SAP ECC

Refer to SAP Note 1342195 for prerequisites to confirm that stock transfers are scheduled consistently between SAP ECC and SAP SCM.

Stock transport order deliveries (created in transaction VL10b in SAP ECC, for example) can sometimes fail to be created if the stock transport order document does not exist in SAP SCM. Here is an example of how this can happen:

• Material A is defined for primary stocking plant X in SAP ECC. Material A at Plant X is part of a CIF integration model for sales orders or purchase orders. After CIF activation the product or location exists in SAP SCM.
• A regional distribution center (Plant Y) suddenly has an urgent requirement for the material. The master data team duly extends Material X to Plant Y in SAP ECC. CIF integration models are usually regenerated periodically (for example, daily). So Material A at Plant Y is not transferred to SAP SCM until the next day.
• If now a stock transport order is created in SAP ECC between Plant X and Plant Y, an SAP ECC ATP check is carried out, and the document is created without error. (The document is not transferred to SAP SCM, however).
• Now if a delivery is attempted to be created in SAP ECC, it fails. The reason is that the ATP check during the delivery creation is based on the shipping plant. The shipping plant is already part of the ATP check integration model, so the Global ATP check is done in SAP SCM. However, the stock transport order itself (being a type of purchase order) is selected in the CIF based on the receiving plant, and it does not exist in SAP SCM.

The reason to provide this rather lengthy explanation is that users are often surprised to see stock transport order deliveries fail even though there is sufficient stock, and the stock transport order document itself was created without error. The solution for this problem, of course, can be to regenerate CIF integration models with higher frequency (several times a day if feasible). Once integration models are regenerated, the master and transaction data is available in SAP SCM, and the delivery can be created effectively.

This example emphasizes the point made at the beginning of this article: Although you may want to implement Global ATP only for sales orders and are satisfied with the basic SAP ECC ATP check for stock transport orders or stock transport order deliveries, SAP does not provide a standard way to perform an ATP check for sales orders in SAP SCM and an ATP check in SAP ECC for other documents.

Confirmation Blocks 

Your specific business scenario should determine whether a delivery block on an order should have confirmed schedule lines or not. You can configure this in transaction OVZ7 (Figure 19) for delivery blocks in SAP ECC.

Figure 19

Confirmation blocks for delivery blocks

Note that if sales order lines are not confirmed owing to a delivery block, supply (for example, inventory) is not reserved for the blocked sales order and may be used to commit to other orders. When the delivery block is removed, there might not be sufficient supply to confirm the order. Typically, while defining variants for back-order processing in Global ATP, you exclude orders with a confirmation block. See the Consider Conf. Lock check box in Figure 20.

Figure 20

Back-order processing filter for confirmation block

Back-order processing may put back a credit block on sales orders that were previously released from a credit block manually in SAP ECC (using transaction VKM3). This point is something that you need to consider and discuss with the team implementing credit control.

Note that an availability check triggered through credit block release (using transaction VKM3, for example) is treated as a background activity rather than as a dialog activity (for example, using transaction VA01). Consider this when setting up availability checking rules for sales areas (transaction OVZJ) (Figure 21). Otherwise, you might get different ATP results when using credit block release compared with sales order create or change.

Figure 21

Availability check rules by sales area

This step is also important when you are assigning a rule strategy or rule strategy sequences when implementing rules-based ATP (transaction /SAPAPO/RBAC01). Technical scenario BB (background job) is required for rules-based ATP triggered through credit block release (Figure 22).

Figure 22

Assign a rule strategy or rule strategy sequence

Subsequent Document Flow

In scenarios in which sales orders are generated from a reference document (such as a quotation), the reference document numbers are not copied at the sub-item level in a rules-based ATP scenario. For example, consider the following scenario: You have created a sales order with reference to the quotation. The reference document number (the document number of the quotation) is populated on the main item in the case of rules-based ATP. The items that are relevant for delivery are the sub-items. Suppose in your business, you need information of the quotation during the delivery process, but this information is not available at the sub-item level. You must plan for custom enhancements to populate the reference document number at the sub-item level.

Back-Order Processing

If the ATP check is performed using Global ATP for a material or plant, back-order processing or rescheduling cannot be carried out in SAP ECC. Instead, you should use back-order processing in Global ATP.

We recommend setting up publication information for back-order processing results of stock transport orders back to SAP ECC via transaction /SAPAPO/CP3 (Figure 23). Although this setting is not mandatory to send confirmation changes back to SAP ECC, without this configuration, multiple objects across location products are blocked in inbound queues in SAP ECC even if there are issues with just one location product. Refer to SAP Note 489151 for suggestions on setting the unified block flag to make the CIF inbound queues into SAP ECC material related.

Figure 23

Publication settings for stock transport orders

Depending on how back-order processing is set up, it could lead to a very large number of order lines being updated in SAP ECC. This can have several implications:

• Performance impact of the CIF owing to the large volume of data
• Frequent order acknowledgments sent to customers (especially if you use Electronic Data Interchange [EDI] or other automated processes to send order acknowledgments)
• Difficulty in measuring performance-to-commit (customer committed date versus actual delivery date)

One reason this problem could occur is if you commit using checking horizons (as defined in the check control configuration in SAP SCM transaction /SAPAPO/ATPC04_05), back-order processing may update order lines simply owing to passage of time, even if there is no change in supply or demand. Another reason could be based on the sort criteria used. If you sort based on customer priority, you are likely to have a higher number of updates than if you sort based on the order create date.

Field Catalogs

SAP delivers a standard list of fields that are transferred from SAP ECC to SAP SCM during the Global ATP check that can be used to control product allocation, rule-based ATP, and transportation and shipment scheduling. You can see the standard list of fields in structure /SAPAPO/KOMGO (for rules-based ATP and product allocation) and structure /SAPAPO/KOMGU (for scheduling). Refer to SAP Note 174969 for instructions on how to extend the field catalog for nonstandard (including custom) fields.

For stock transport orders, all fields available in the standard system are saved in the table /SAPAPO/MM_DOC. Refer to SAP Note 821934 for instructions on how to enhance the field catalog.

In the field catalog there are multiple options for characteristics such as material and location. For example, material needs MATNR in one context and RULE_MATNR in another context (in the context of RBA for example). Refer to SAP Note 655833 for help on how to choose between multiple product and location characteristics in the field catalog.

When you are using rules-based ATP with product or location substitution, it does not make sense to use some fields in the field catalog for scheduling, such as Route or Shipping Point, because route and shipping point determination occurs in SAP ECC before the Global ATP check is called.

For example, consider the following scenario: If a substitute source plant is determined by rules-based ATP, there is no route or shipping point determination in SAP SCM for this substituted location. So if you had maintained condition tables for transit duration based on route (which is determined in SAP ECC only once prior to the Global ATP check), the result would be incorrect because it does not account for the location substitution. Therefore, the solution would be to maintain condition records that take into account this substitute location to determine information such as the transit time.

Transportation and Delivery Scheduling

In the case of a Global ATP check for stock transport orders, you can use transportation lanes to determine transit times. If you do so, you can optionally map the shipping conditions from SAP ECC to means of transport in SAP SCM. This step allows you to determine different transit durations based on shipping conditions on the SAP ECC stock transport order. The menu path to map the shipping conditions to means of transport is mySAP SAP SCM - Implementation Guide > Advanced Planning and Optimization > Global Available-to-Promise > Transportation & Shipment Scheduling > Interfaces > Define Assignment of Default Means of Transport to Shipping Conditions (Figure 24).

Figure 24

Assign means of transport to shipping conditions

Demand and Supply Planning

Demand Planning (DP) usually uses order or shipment history to generate statistical forecasts and to generate proportional factors for disaggregation. Product or location substitution using rule-based ATP can change this history and therefore affect DP. For example, if a customer requests Product A, but during order entry, you substitute Product B because A is not available. For calculating history for DP purposes, you may want to merge the two products because the customer had originally requested Product A, and that’s the product for which you want to stock and plan.