Commitments to customers are critical and they must be reliable from the start if you expect to build a long-lasting business relationship. Your customers must be able to rely on when you'll be able to provide them with certain products. If your promises don't become reality, the results will all too likely be your customers rushing straight into the arms of your competitors.

Regardless of the high stakes, it is becoming increasingly difficult to accurately answer the simple question: "Are we able to deliver on time?" Product portfolios are steadily increasing and firms are required to accommodate orders that range from many items in big lots to reduced quantities for special purchases as they grow from local markets to a global market and shift strategies from "make-to-stock" to "make-to-order." As the scope of the business continues to change, reliably answering questions related to delivery is a growing challenge.

SAP provides technology to meet the challenge of providing availability information across a global enterprise. If you're familiar with the Sales and Distribution (SD) module in SAP R/3, the concept of available to promise (ATP) is not new to you. The ATP feature in R/3 provides check capabilities that deliver great results for basic business scenarios. More complex scenarios, however, require more robust capabilities to make delivery commitments that are in line with the real-world demands. In short, global scenarios require global solutions.

Global ATP — or GATP — takes advantage of SAP APO technology and picks up where the SAP R/3 ATP solution leaves off. Both allow a company to allocate products across distribution chains on predetermined criteria. The two systems can be configured in tandem to allow for greater versatility. For more details, see the article, "Enhance R/3's Product Allocation Tool by Integrating It with APO's DP and GATP Modules." I will focus on the various ways GATP allows you to answer questions related to promising products to your customers. You'll get an overview of the technology along with some insight into the different methods of GATP functionality. I will also present examples of GATP in action along with some simple but important settings. My goal is not to explain the full ATP check functionality available from SAP but to focus on improved scenarios with GATP. I do, however, provide references where you can find more information about other ATP methods. Most of the functionality I describe is available in SCM 4.0, but I also will offer you a glimpse at some improvements coming with new SCM 4.1, which is slated for release in the second quarter of this year.

GATP Technology

GATP quickly makes information available to provide real-time optimized decision support. GATP can be deployed in heterogeneous landscapes and offers the functionality to perform availability checks in SAP APO. These checks consist of online searches that determine if requested products are available at requested times in the quantities that satisfy customer demand.

GATP processes run on the time series supported by SAP liveCache, which is a tool for processing large volumes of data and enable data sharing among several applications. SAP liveCache has a large main memory and behaves like both an object-oriented and relational database. It stores data in optimized structures and allows concurrent data access.

A time series represents receipts and requirements for a product, location, and so on in an aggregated form (Figure 1). A time series is managed separately for each planning object, which includes some combination of product, location, account assignment, and planning segment, and is updated when planning object changes are made. An individual time series is uniquely identified by a key consisting of category, sublocation, version and, in the case of the characteristics-based product availability check, by a valuated characteristics combination.

Figure 1

Concept of time series (the bars represent quantity)

As of SCM 4.0, GATP also supports inverse logistics to accommodate customer returns so that SD returns and deliveries are considered by GATP. SAP R/3 cannot do this. SAP APO can consider those elements as planned receipts, increasing the ATP quantity that leads to a better service level. SCM 4.1 will also support continuous output to solve problems that arise with long-running process orders, which can reduce stock visibility. Currently, the system considers material available when an order is finished processing, but this significantly reduces the quantity available to promise. SCM 4.1 offers an improved availability check by taking into account the continuous flow in process manufacturing used by the chemical and petroleum industries. The new technology simulates the continuous output against discrete production where the full quantity is available at the end of the order.

GATP methods can be classified into three areas:

• Basic methods and combination
  
  
• Rules-based ATP (RBA)
  
  
• ATP integrated with production

The basic methods were available in SAP R/3 and include product check, product allocation, and check against forecast functionality that have been enhanced with SAP APO capabilities. The other two methods were introduced with SAP APO. I will walk you through each one.

Basic Methods

A basic product availability check generates positive results if the so-called ATP quantity for a product is available on the requested delivery date. If it is not available, a new delayed delivery date is proposed. The ATP quantity referenced during the product availability check is based on categories defined in Scope of Check screen (Figure 2), which is accessed via menu path IMG > APO > Global ATP > Product Availability Check > Maintain Check Control. The availability of an ATP quantity is defined by establishing the dependent demands, required sales orders, scheduling agreements, and more on the Reqmts tabs. On the receipts tab (Recpts), the ATP quantity can be defined at different risk levels that reflect your firm's degree of conservativeness.

Figure 2

The defined categories on the Scope of Check screen determine the ATP quantity referenced during the product availability check

The second basic method is product allocation (PAL). Using information in the DP module, PAL lets you know your availability to promise when sales orders compete for quantities in a constrained supply chain. New products, production downtimes, and other factors lead to fluctuating demands, which can affect product supply. For these situations, PAL provides a tool to ensure a better distribution of the total amount when a company cannot deliver the full available quantity to a customer.

Figure 3 shows a typical PAL process where a sales order is introduced at the end of the week 7 (dashed white box), but due to the predetermined quotas (dashed lines) and already consumed amount by orders 1, 2 and 3, the new order, 4, can only be confirmed partially at week 7 and the rest in week 8.

Figure 3

ATP PAL check showing sales order created at the end of week 7

Sequencing several allocation procedures allows you to model complex scenarios where various product allocation checks are performed using PAL. I will present a real PAL scenario as an example of method combination later.

The last method on the list is a check against forecast. It provides a check method that is especially important in make-to-order environments, where inventory is not available to confirm the quantity ordered by the customers. In this case, the quantity confirmation is performed against the forecast. Like PAL, this functionality is integrated with the DP module.

Rules-Based ATP

In branched supply chain networks, rules-based ATP allows companies to take full advantage of multiple shipping assets to ship goods from alternative sites to customers. In addition, it permits certain products to be substituted as required to successfully satisfy customer demands.

Different nodes of a supply chain can be used to ship goods following a predetermined sequence or with different products using rules-based ATP. Substitution rules are established that drive an iterative availability check process. Substitutions can be processed across several axes: product, location, or characteristics for batch selection.

Here's a simple example of how rules-based ATP works. A 200-piece order is introduced into R/3 and the rules-based ATP tool starts checking all locations defined in the rule scripted for this sales order.

Normally, a facility in Dallas supplies this customer, but only 70 pieces are available in Dallas. Following ATP rules, SAP APO then checks other locations and finds 55 pieces in Seattle and 20 in Orlando. It determines that a full delivery is still not possible. As a result, the system looks for an alternative product with similar value for the customer and substitutes that item the original. It follows the same substitution rule for locations until the order is filled.

The availability check for this sales order and the resulting substitution chain is shown in Figure 4. It depicts the top-down sequence structured such that each step checks the availability of the requested material at each location and reports the findings. Any substitutions are performed at the end of the sequence, and locations that have substitution products remaining are accounted for in the last line to inform the user.

Figure 4

SAP APO ATP screen, result of the substitution chain shown during sales order creation

When running substitution checks, you can control which activities are performed, such as triggering a new availability check or producing the missing product. During the ATP check, SCM 4.1 users will also be able to customize the information screen in Figure 4 so they can verify the result or skip it before getting the proposed items (Figure 5).

Figure 5

R/3 sales order (transaction VA01) after rules-based ATP determines the deliver plant and quantities

Two settings are used to determine rules-based ATP activities. The substitution rules are established in the Rule Maintenance screen (Figure 6), which is accessed via menu path SAP APO menu > Master Data > Rule Maintenance. These rules are maintained for individual products and locations or for characteristics or PPMs if required (Figure 7). The rules drive the substitution process and are used to fulfill items in a sales order from different locations or with different products. The validity of the substitutions, how to combine types of substitutions, and other controls are defined within a rule.

Figure 6

Rule definition with the substitution procedures

Figure 7

Rule for location substitution

The condition technique, which is commonly employed to establish pricing in other modules such as SD and MM, can be used to determine rules for rules-based ATP. For more details on the condition technique, see "Condition Technique: Meet Complex SD Pricing Requirements More Easily."

You can establish different rules for different criteria with the condition technique. For instance, customer 1 can be assigned a rule with the sequence that calls for a check of products from Dallas then Seattle then Orlando. Customer 2 can have a separate sequence that calls for the check to go from Dallas to Orlando to Washington.

As location or product substitutions are performed, batch selection criteria in rules-based ATP introduces rules for characteristic substitution. For instance, when a customer orders a product of medium quality, if it is not available, a different batch with high quality can be offered instead.

Capable-to-Promise (CTP)

CTP technology taps into SAP APO Production Planning and Demand Scheduling (PP/DS) functionality. A GATP check executes a detailed report on any bottlenecks along the supply chain in real time. Technically speaking, CTP triggers an online check when a sales order is created. If the supply cannot cover the new demand, the PP/DS functionality is called on as a part of the ATP check.

Here's how it works. Let's say a 200-piece sales order is created for an end item at 9.2.2005. A temporary requirement is created in SAP APO. It is a simulated demand or virtual requirement that is created temporarily and deleted after the availability check. The temporary requirement is transparent to the user (Figure 8) and it triggers an immediate planning process through all levels of components and corresponding plants to determine the availability to promise.

Figure 8

Simulated requirement during the sales order creation

The temporary requirement initiates automatic planning in SAP APO for the item and PP/DS involved. A new planned order is created (174069) and scheduled from the day the order is processed, and the final availability of the product is determined. Figure 9 on the next page shows the steps that must be taken to produce the order Prepare material, Assemble, etc. Because of these steps, the date 6.5.2005 is established as the final availability date of the planned order, based on resource capacity. The planned order resulting from the sales order requirement is scheduled through the resources of production routing, while taking into account at the same time the availability of the components.

Figure 9

Temporary planned order which determines the final availability date

Accessed via menu path APO > Master Data > Product, the settings on the PP/DS tab in SAP APO for product master data (Figure 10) enable the CTP function in GATP. The tab is maintained so as to start the planning process automatically. If, for example, the Cover Dependent Requirements Immediately option is selected, a product heuristic for a specific product is called immediately when a sales order is created or changed. In general, the PP planning procedure determines the actions to be executed after a planning event: sales order creation, goods movement, planned order change, etc.

Figure 10

The Planning Procedure in product master data is maintained on the PP/DS tab

If you'd like to model this scenario on your system, the SAP note 426563, "CTP: Settings, system behavior and performance," offers more information including recommendations and restrictions.

Multilevel ATP

Multilevel ATP represents an evolution of the ATP checks available since the introduction of SAP APO 3.1. Originally delivered for personal computer manufacturers, multilevel ATP provides information for assemble-to-order scenarios. It is especially helpful for business scenarios that require products to be configured for individual customers.

Basically, multilevel ATP explodes a bill of material (BOM) for the assembled product, then checks the availability of each item at the component level. A multilevel ATP check determines the availability of each component required by the finished good. A big difference between this check and CTP is data is stored in the ATP tree. It's a new object that prevents the creation of the receipt elements generated by CTP. Consequently the trees structures are not included in planning processes.

Figure 11 offers an example with a sales order created for 100 units of end item ML-109. It was requested on the current date, which I've called 31.1.2005. During the ATP check, SAP APO checks each BOM level including ML-100, ML-600, etc. in the tree located on the left side of the Figure 11. It attempts to satisfy the dependent demands generated from the upper levels. The result is a final confirmed date restricted by the most constrained component. The delivery is delayed until 15.2.2005 in my example.

Figure 11

Multilevel ATP result overview during sales order creation

If component availability is the critical factor for your planning, multilevel ATP is the best option. Because CTP focuses on detailed scheduling strategies, it is the best choice when bottlenecks are the critical factor. You'll find an interesting comparison of the multilevel ATP and CTP features at https://help.sap.com under the SCM 4.1 Help and Global ATP. SAP note 480292, Multilevel ATP documentation also provides helpful information about the functionality.

Method Combination

You can combine several global ATP methods in Table 1 to provide more advanced capabilities. A steel manufacturer, for example, combined PAL and CTP to solve problems caused by imprecise ATP check results. Steel production is characterized by long lead times and make-to-order manufacturing in complex facilities, leading to a product with hundreds of characteristics including differing dimensions, diameters, etc. Diversity of the characteristics and constrained supply made it difficult to answer, "When can we ship it?" In this scenario, a two-step ATP check was able to cover it.

The PAL function looks for constrained demand by different factors both internal and external. Monthly predetermined assignments by sales area, thermal treatment and so on, give a rough answer to questions related to availability. PAL establishes if the initial shipping month is possible or delivery should be moved. Basically, the system will check the feasibility of the required date through a table similar to Table 2.

If a sales order from area 1 with thermal (treatment) 1 is introduced on January 15, 2005, due to predefined constraints for January, 1,000 pieces will be available but they were previously confirmed. The full amount then can be confirmed, but it cannot be promised until the next month, February. DP and GATP are integrated so the solution uses the capabilities of DP such as macros, forecasting and so on, to calculate and maintain tables like Table 2. Sales documents update ratios for already allocated amount when they are sent via the core interface (CIF) from SAP R/3 automatically.

Once the system gets a previous constrained date, during the second ATP check, CTP is launched. As stated above, CTP creates a new make-to-order manufacturing planned order and schedules finitely required operations on the critical resources checking for bottlenecks. The system can then provide a feasible date while aligning the real load of the facilities and the characteristics of the demanded steel.

Back-Order Processing (BOP)

When processing sales orders and documents, the dictum "First entered, first confirmed" does not always hold true. Priorities can change and result in new promising criteria. BOP is the solution for these situations. It detects and resolves your back-order conflicts (Figure 12). BOP is not only a technical task and its integration into the fulfillment cycle should be analyzed carefully. You must decide such matters as when BOP should be executed, how it is communicated to entities involved, or what receipt elements taken into account by BOP can be covered.

Figure 12

BOP worklist (APO menu>Global ATP>Backorder processing>Interactive BOP)

Basically, BOP consists of three steps: Filter the treated elements, sort those sales documents, and schedule them. BOP is available in SAP R/3 and GATP. In R/3, it is built on predetermined criteria, while BOP in GATP allows configuring the previous steps: filtering, sorting with up to different 20 criteria, and scheduling.

GATP provides functions to execute BOP interactively (manual reconfirming of the sales documents), or as a background or a mixed process such as the interactive processing of a batch run. In this way, BOP can be scheduled as a job during inactive period (night). The BOP Monitor provides the required tool to analyze the changes and results of the background execution. Connected to TP/VS, which can optimize transportation routing and load consolidation processes, BOP is able to reschedule sales order items taking into account the transportation information.

Overview of the ATP Settings

Configuration always depends on the final solution or ATP check process being built. A GATP consultant is usually responsible for configuring availability checks, and when CTP or multilevel ATP is implemented, typically a Production Planning and Detailed Scheduling (PP/DS) expert is consulted with some GATP knowledge — or vice versa. CIF knowledge is required to model the interface between APO and R/3. CTP settings, for example, are integrated deeply into PP/DS. Nevertheless, some common tasks can help you to understand the ATP process as an integrated process among SAP SCM, planning system, and the execution system, SAP R/3.

Integration models between APO and R/3 call for transferring master data and transactional data required for the ATP check. Customers, locations, stocks, sales orders, manufacturing orders, and so on are transferred from R/3 via the CIF or standardized interface solution to SAP APO. In SAP APO, the check is narrowed to relevant products. An ATP channel must be opened between APO and R/3 for the order promising process.

Establishing this channel is simple in our integration model. It only requires setting a flag in the ATP Check flag in the Create Integration Model screen shown in Figure 13. The screen is accessed using transaction CFM1 or following the menu path Logistics > Central Functions > Supply Chain Interface > Core Interface APO > Integration Model > Create. When the model is activated, SAP APO will be the master system for order promising. During the sales order entry, an ATP check will be triggered via a remote function call connection on the SAP APO side instead of SAP R/3. This call is transparent to the user but new screens such as those in Figure 4 or Figure 11 can appear during the ATP process with information about the check results in SAP APO.

Figure 13

CIF setting for ATP check

The main settings in global ATP for order promising methods is the check mode. It groups information for the product as well as the business event linked to a transaction and initiates an ATP check process. The ATP check can then trigger different processes as determined by the Checking Instructions object, which is maintain by following the menu path IMG > APO> Global ATP > General Settings > Maintain Check Instructions.

GATP also provides simulation capabilities for reproducing, investigating, or testing the response of GATP to questions regarding availability or the effect of different planning scenarios. Figure 14 shows the screen to define a simulation scenario while introducing the same conditions as a sales order could trigger. It is accessed via menu path APO menu > Global ATP > Reporting > ATP Simulation. Sales order item information such as product, location, quantity, and date can be defined along with the check mode and business event that simulates the information linked to an SAP R/3 document.

Figure 14

Simulation screen in APO

Adolfo Menéndez Fernández

Adolfo Menéndez Fernández is the application architecture manager at Repsol in Madrid. Previously, he worked at SAP Consulting Spain as the logistics consulting manager. He studied at the University of Oviedo, where he earned an electronic engineering degree. He is a certified SAP consultant in supply and demand planning (SNP and DP), order fulfillment (Global Available-to-Promise), production planning and detailed scheduling (PP/DS), as well as procurement and materials management (MM). Adolfo has more than 10 years of SAP implementation experience in the consumer product goods, pharmaceutical, automotive, furniture, textile, chemical, oil & gas, and steel industries using SAP ERP logistic modules (including PP, MM, and sales and distribution [SD]) as well as SAP SCM (DP, SNP, and PP/DS). He is APICS certified in Production and Inventory Management (CPIM).

You may contact the author at asturiasadolfo@yahoo.com.

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