Understanding GATP

Page 1 of 19

Understanding GATP
Document ID: RG-GATP Version 1.0 - 16 June 2004

Overview
About this document
This document describes GATP. It explains what GATP is, what it does, and how it is used for XXXXXXXX.

Audience
This document may be helpful to anyone involved with GATP. Specifically, it may appeal to the following user groups:
l l

CSRs who want to understand the impact of GATP checks on order entry. Sales Representatives who want to understand how allocation and availability are handled by GATP. Demand Planners who want to understand the impact of GATP on demand planning. Production and Replenishment Schedulers who want to understand how availability checks work.

l l

Using this document

Identifying new concepts This document introduces a number of new, inter-related concepts. Because an understanding of some of these concepts relies on an understanding of other concepts, some terms may be introduced before they are fully explained. These terms are identified with 'q.v.' (quod vide meaning 'described elsewhere in this document') the first time they are used. It is recommended that you read this document from beginning to end, to familiarize yourself with all concepts, and the overall content of the document. Subsequently, you may find it adequate to jump directly to single topics to refresh your understanding, as required. Understanding the ATP diagrams This document includes a number of diagrams designed to show how sales orders and other events affect ATP levels. Each diagram charts the ATP level (and in some cases the physical inventory level) against a range of dates. It is important to understand that these charts do not show the expected ATP level on day X from the vantage point of today (that is, looking 'forward' to day X). Instead, they show the actual ATP level on day X from the vantage point of day X (i.e., when day X is today). That is, the ATP on day X will only appear as the level shown on the diagram once day X has been reached. SAP calculates ATP between planned production orders. Given this, and because orders

Understanding GATP

Page 2 of 19

entered into the system will consume ATP from the moment they are entered, the ATP level will only appear to change in response to planned production. Therefore, the diagrams used in this document do not necessarily reflect what you would see if you displayed the ATP level in the system itself. The diagrams are presented the way they are because they are conceptually easier to understand in this form. See also "ATP in APO - An Example", below, for additional explanation of how ATP appears in the system.

Document summary
1. An introduction to GATP 2. Availability 3. Allocation 4. GATP at order entry 5. How ATP is consumed 6. Backorder processing

An introduction to GATP
What is GATP?
GATP is an abbreviation of Global Available To Promise. Available To Promise (ATP) is a term used in Sales and Logistics to refer to the level of inventory that is (or will be) available for use on a given date. Typically, this 'use' is for allocation to a sales order or stock transport order. Conceptually, then, the term 'Available To Promise' refers to stock that is available and can be 'promised' to (for example) a customer. ATP checking(1) considers availability at one or more plants within a sales organization. Global ATP simply extends the concept of GATP to a global basis, by making the ability to check ATP available globally (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX).
(1)

Strictly speaking, the term ATP refers to the actual available inventory level, and the term GATP refers to the system functionality that provides this information. These terms are used in this context throughout this document.

The R/2 system XXXXXXXXXXXXXX XXXXXXXXXXXXXX provided ATP checking. As XXXX XXXXXXXXXXXXX, GATP supersedes ATP.

GATP and APO

GATP functionality is provided by a specific module within the SAP APO (2) Technically, allocation checks are system. This module is often referred to simply as 'the GATP module'. performed via CIF, and APO (Advanced Planning and Optimization) is the XXXX planning and availability checks are forecasting system (as distinct from SAP R/3, which is the transactional performed via an RFC call. system). Because GATP is examining future availability, it naturally sits within the planning system. Note, however, that although APO is a distinct SAP system, it is seamlessly integrated with the R/3 system, and information flows constantly, and automatically, between these two systems.(2)

Allocation vs. Availability

Understanding GATP

Page 3 of 19

Although GATP is Global Available To Promise, the GATP module provides the ability to check product requirements against two things: availability (q.v.) and allocation (q.v.). Whereas availability considers the total amount of inventory available, allocation considers the amount of product that will be made available to individual customers. Put simply, availability is a check against inventory, and allocation is a check against a predetermined amount that has been reserved ("allocated") for a customer (based on forecast, historical offtake, or other businessspecific basis). ATP refers to product that is both available and allocable (capable of being allocated). If GATP determines that there is insufficient ATP for either of these reasons, then the order is blocked.(3)
(3)

Activating GATP

In fact, GATP never 'blocks' an order - the CSR must either resolve the issue before saving the order, or save the order as incomplete (and therefore unconfirmed).

Although GATP is 'global', GATP functionality is actually activated ('turned on') per material/plant combination. That is, if GATP is activated for Product A at plant US01, then GATP checks will be carried out for all orders of Product A that are to be supplied from plant XX01. Orders of Product B from plant XX01, or orders for Product A from plant XX02, will not be checked against ATP (unless, of course, GATP is also activated for these specific combinations as well). GATP can be activated for availability checks, or for allocation checks, or for both. Whether GATP is enabled or not for a specific material/plant combination, and whether it is enabled for allocation, availability, or both, is decided by the Supply Chain according to local Business Rules.(4) For additional information on the technical steps required to enable GATP, refer to the document "Enabling GATP".
(4)

Although allocation and availability are activated at the material/plant level, allocation may actually be checked at another level of aggregation (see "Allocation activation vs. allocation checking", below).

Availability
ATP vs. physical inventory
It is important to understand that available inventory (which is ATP) is not the same as physical inventory. For example, even though there may be 1,000 units of a product physically located in the warehouse, this does not necessarily mean that all 1,000 units are available. This is because some or all of this product may have already been allocated to sales orders or Stock Transport Orders that just haven't shipped yet. It is also important to note that ATP is not the same as the projected inventory that appears in the Stock Requirements list in R/3 (MD04 transaction) or the Product View/Stock Chart in APO.

What constitutes 'available'?

When GATP checks inventory, it first determines the requirements date (q.v.). This is the date on which the product must be available in inventory, in order to meet the requested delivery date. The requirements date is determined by working back from the requested delivery dated, taking into account all applicable lead times. Once GATP has determined the requirements date, it checks the cumulative ATP level (q.v.) for the requested product, at the specified supply plant, on that date. If the requested quantity is not available on the requirements date, the system find the earliest date on which the required

Understanding GATP

Page 4 of 19

quantity is available, and then re-applies the lead times to move this date forward and obtain a confirmed delivery date. This is summarized in the following diagram:

Figure 1: Checking availability backwards then forwards In this example, an order is entered (Event 2) on Day 2, for 40 units, with a requested delivery date of Day 6. The system works back from the requested delivery date, taking into account the total lead time, to determine the requirements date (Event 3) of Day 4. The system then checks ATP to determine an availability date (Event 4) of Day 5. The system then goes forward from this, based on the previously-calculated lead time, to determine a confirmed delivery date (Event 5) of Day 7. Note that in this example, that even though there was sufficient ATP on the requested delivery date, GATP could only confirm a delivery date of the day after the requested delivery date.

Determining the requirements date

The requirements date is determined by working back from the requested delivery date (which is the date on which the product is required at the ship-to location), taking into account all applicable lead times. This is known as order scheduling, and (XXXXXXXXXXX) is performed in APO by the GATP module (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX). Order scheduling calculates a number of successive dates to determine the eventual requirements date. These dates are as follows: 1. Requested delivery date: The date on which the product should arrive at the ship-to location. This date is specified in the order. 2. Goods issue date: The date on which the product must physically leave the shipping point in order to reach the

Understanding GATP

Page 5 of 19

customer on the requested delivery date. This calculated by subtracting the transit time from the requested delivery date. Transit times are defined for routes, in the R/3 Route Master File. 3. Loading date: The date on which the finished product must be physically available for loading onto the vehicle in order to allow the vehicle to be dispatched on the goods issue date. This is calculated by subtracting the loading time from the goods issue date. Loading times are defined for a material/shipping point combination, in the R/3 Material Master File record for the product. 4. Material availability date: The date on which the material must be available for picking and packing to start. This is calculated by subtracting the picking and packing time from the loading date. Picking and packing times are defined for a material/shipping point combination, in the R/3 Material Master File record for the product. 5. Transportation planning date: The latest date on which transportation planning can start in order for the product to be dispatched on the goods issue date. This is calculated by subtracting the transportation planning lead-time from the loading date. Transportation planning lead times are defined for routes, in the R/3 Route Master File. Note that both the material availability date and the transportation planning date are calculated from the loading date. This is because both transportation planning and picking and packing can take place in parallel (but must both be complete by loading time). The calculation of these dates is summarized in the following diagram:

Figure 2: Calculating the requirements date

Calendars
When determining the various dates above, the system will take into account the calendars at

Understanding GATP

Page 6 of 19

the shipping plant and ship-to customer location (or receiving plant, for STOs). Each calendar specifies the days and dates on which the location is in operation (for example, Monday to Friday only, not on Public Holidays, and so on). The calendar also specifies the actual hours on each day for which the location is in operation. In this way, the GATP module will determine the requirements date to the nearest hour. GATP will use the location calendars that are defined in APO(5), and assigned to locations in the APO Location Master. However, if a calendar has been assigned to the customer unloading point in R/3, then that calendar is used in place of the location calendar in APO.
(5)

If a specific calendar has not been assigned to a location (either in APO or R/3), then GATP uses a default calendar that specifies the following operating hours:
l l

R/3 also provides calendar functionality. However, R/3 calendars work on a daily basis, whereas APO calendars work on an hourly basis.

Customer locations: 24 hours a day, 7 days a week (a.k.a. '24/7'). Plant locations: Midnight to 5 P.M., Monday to Friday only (a.k.a. '17/5').

The checking horizon

GATP considers availability of product on a certain date in the future. However, depending on how far into the future the product is required, it may not necessarily be worth checking availability. For example, if the production lead-time for a product is 30 days, then it may not make sense to check availability for a requirement due in 40 days, because additional product could always be manufactured within that period if necessary. Similarly, if production of a material is only planned three months in advance, then it is not worth checking requirements more than three months out, because this cannot take into account the unplanned production. To cater for such scenarios, GATP uses a checking horizon, which specifies the period into the future beyond which availability will not be checked. If the requested delivery date(6) for an order is beyond this horizon, then the order will not be checked for ATP (that is, the product will be assumed to be available). This is illustrated by the following example:
(6)

The checking horizon considers the requested delivery date and not the requirements date, as the requirements date is determined by the GATP module, and the point of the checking horizon is to avoid calling the GATP module.

Figure 3: The checking horizon The checking horizon is specified per product, and is determined by the ATP group assigned to a product in the Material Master File record for that product (in the MRP 3 view). XXXX provides the following ATP groups:

Understanding GATP

Page 7 of 19

l l

XX: Always check ATP (checking horizon effectively infinity). XX: Use the total replenishment lead time specified in the Material Master File record as the checking horizon. XX: Never check ATP (checking horizon effectively zero).

Calculating ATP
The ATP level for a material may be constantly changing as product is issued (to sales orders and outbound replenishment) and received (from production, procurement, and inbound replenishment). What is available today will be different from what will be available tomorrow (or even what will be available later today). To calculate ATP on the requirements date, GATP starts from the current stock level, and then takes into account all planned product movements (both inbound and outbound) between the current date and the requirements date. Specifically, the GATP module will calculate ATP as follows:

Open sales orders + Scheduled deliveries + Dependent requirements (use as component, etc.) + Planned outbound replenishment (STOs) + Reservations Planned outward movements

Planned production orders Unrestricted stock + Stock in Quality Inspection ATP = Current stock level + + Planned purchases + Planned inbound replenishment (STOs) Planned inward movements

Blends and re-brands For orders of blends and re-brands, the system will 'decompose' the product into its various components, and then perform an ATP check for each of these components. If any component fails the GATP check, then the entire (finished) product is considered to be unavailable. Continual production Due to the SAP design of APO and R/3, GATP does not recognize 'continual receipt' from production. For example, if there is a production order for 10 Million tons, this may take four days to complete. However, in reality, the product is continually coming off the production line and being physically received into inventory (or, in the U.S. possibly directly into a hopper car). Although in practice there are 2.5 million tons physically available at the end of each day of the four-day run, GATP does not recognize any product as being available until the end of the entire production run.

ATP in APO - An Example

Understanding GATP

Page 8 of 19

The following table, which is based on actual data extracted from the APO system (using transaction /SAPAPO/AC03/) illustrates how ATP is calculated: Req'ts Date Category (Event) Requirements 0 25,000 102,000 103,040 102,720 102,660 275,700 156,600 33,960 196,556 0 50,000 125,000 196,000 0 119,000 102,560 940 98,644 0 300,000 136,000 100,000 102,000 109,000 196,000 0 Cumulative ATP 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 118,686 314,686 Impact on Projected ATP Inventory 118,686 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 196,000 1,673,666 1,648,666 1,546,666 1,443,626 1,340,906 1,238,246 962,546 805,946 771,986 968,542 918,542 793,542 989,542 870,542 767,982 767,042 865,686 565,686 429,686 329,686 227,686 118,686 314,686

Line 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Receipts 1,673,666

26-May Current Stock 04-May Delivery 07-May Sales Order 18-May Delivery 19-May Delivery 20-May Delivery 23-May Delivery 24-May Delivery 25-May Delivery 26-May Planned Production

26-May Delivery 26-May 27-May Outbound Replenish. Planned Production

27-May Delivery 27-May 28-May 28-May 02-Jun Issue against STO Issue against STO Planned Production Issue against STO

03-Jun Sales Order 03-Jun Issue against STO

04-Jun Sales Order 04-Jun Delivery 05-Jun Planned Production

In this table, the Cumulative ATP column shows the actual ATP level. The Projected Inventory column (which is not available in the system but has been added here for illustration) shows how each event affects the ATP level, and therefore how the Cumulative ATP figure is calculated. This snapshot was taken on 26 May, and Line 1 shows the ATP level on that date (118,686 Kg). This is the ATP quantity against which any orders subsequently entered (with a requirements

Understanding GATP

Page 9 of 19

date) between 26 May and 05 June will be checked. So an order for 120,000 Kg for delivery on 01 June will fail the ATP check, but an order of 110,000 Kg would be accepted. This cumulative ATP level remains the same up until the next scheduled production receipt that is not entirely consumed by requirements (Line 23). The receipts on Lines 10, 13, and 17 are all consumed by current requirements and so do not affect the ATP level - for example, the sum of the requirements on Lines 2 to 9 is 901,680 Kg, which is greater than the planned receipt on Line 10 of 196,556 Kg. See also "How ATP is consumed", below, for more information. Lines 2 to 22 represent events that are currently consuming ATP. The lines shaded in this example (Lines 2 to 9) are events with a requirements date in the past. Normally these requirements should have been fulfilled by the current date, but for some reason have not. For example, Line 2 shows a delivery scheduled for dispatch on 04 May but for which the Goods Issue has not yet been recorded.

Allocation
Overview
As explained above, GATP can check both availability and allocation. Whereas availability considers the total amount of inventory available, allocation considers the amount of product that will be made available to customers. That is, the product may actually be available, but it will not necessarily be sold to any customer who wants it. Allocation therefore allows control over the amount of product sold to customers. Allocation is a check entirely independent of the availability check. That is, a sales order may be 'blocked' because it fails the allocation check, even though there is adequate inventory available to fulfill the order.

Allocation scenarios
There may be many different reasons for using allocation checking. Some of the more common reasons are:
l l l

To implement sales control. To implement legal sales control (a.k.a. 'allocation'). To facilitate XXXXXXXXXXXXXXXXXX.

These scenarios, and they way in which allocation is used in them, are discussed below. Implementing sales control Under this scenario, allocation levels can be based on (for example) the sales forecast or historical sales. Allocation checking is then used to effectively validate the accuracy of this forecast. This may be done for a number of different purposes. For example, it can be done to:
l l l

Encourage accuracy of the Sales Representative's forecast; Ensure that Sales Representatives do not 'over-sell'; Ensure that a customer does not suddenly order more than their usual volume, thereby

Understanding GATP

Page 10 of 19

generating a potential shortage for other (potentially higher-category) customers; This type of allocation is typically initiated by the Sales Manager. Implementing legal sales control Legal sales control refers to a situation where sales of a specific product are tightly controlled due to a market shortage of the product. This type of allocation is typically used to ensure that all customers have an equal opportunity to purchase the product. Without allocation, customers would be able to order the product on a first-come-first-served basis, potentially stopping customers who order later in the month from obtaining the product. This use of allocation is sometimes referred to as 'Allocation', to distinguish it from the 'non-legal' sales control scenario described above (which is then referred to simply as 'Sales Control'). This type of allocation is typically initiated by the Supply Chain. Facilitating XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.

Setting up allocation quantities

Allocation quantities are set and entered per material/customer combination. Depending on the reason for using sales allocation (see above), the quantities to be allocated may be determined in a number of ways. Typically, one of the following ways is used:
l

Based on historical sales - for example, the monthly average of the customer's purchases over the previous year. Based on the sales forecast. Based on the amount of product that will be physically available (this method is typically used for legal sales control). In this case the amount of physical product available may apportioned amongst the customers according to historical sales, the sales forecast, the customer category, or some other suitable criteria.

l l

Regardless of the basis, allocation quantities are initially defined in Planning Books in the Demand Planning (DP) module of APO. Allocation quantities can be entered at any level of aggregation (from sales organization down to ship-to party), and are automatically disaggregated down to the ship-to party level. These quantities may then be adjusted (either manually or via an automated macro) and/or rounded (for example, rounded up to the nearest truckload). Once the quantities have been finalized, they are copied to Planning Books within the GATP module. Allocation checks are then performed against the GATP Planning Books, and any adjustments made during the month must also be made in these books.

Understanding GATP Allocation periods

Page 11 of 19

Product is allocated per calendar month. That is, the amount of product that a customer (for example) can order is set monthly, and is reset at the end of each calendar month. If a customer attempts to order product but has exceeded their allocation for the month, they have the option to place the order as early as the 1st of the next month, when a new allocation quantity will normally be available. Allocation is reductive. That is, each successive order placed by a customer during the month will reduce the remaining allocation available. Specifically, it does not apply on a per-order basis (which would be an order quantity cap). Depending on configuration (which is performed separately for each Business Unit), it may be possible to 'carry forward' ('roll-over') unused allocation from one month to the next, or to 'borrow' configuration from the next month. This is often done to overcome situations where a customer's purchases do not follow a strict month-by-month pattern. For example, consider the case where a customer always orders 10 Tons, every second month. Allocation based on historical sales would average this to 5 Tons per month. If the monthly boundaries were strictly enforced, then customer would be blocked on every bi-monthly order (because the order quantity of 10 Tons exceeds the allocation quantity of 5 Tons), even though they are not using any allocation in the intervening months. Using the prior-month's unused allocation, or consuming the next month's allocation can alleviate these kinds of problems. Note that the allocation check is performed against the planned goods issue date, and not against the order entry date or the requested delivery date. Also note that allocation consumption is based on the order quantity, and not the quantity actually shipped (which may be different).

Allocation activation vs. allocation checking

Once allocation quantities have been entered (and copied to the GATP Planning Books), allocation checking must be activated so that the assigned quantities are checked at order entry time. This activation is done in the R/3 system (and not in APO), and is done at the material/plant level. However, although allocation quantities are (ultimately) set at the product/sold-to party level, and activated (that is, 'switched on') at the material/plant level, allocation quantities may be checked at one of a number of other levels of aggregation. That is, for an order of product X for customer Y, the order quantity may not necessarily be checked against the allocation quantity assigned to that individual product/sold-to party combination - it may be checked against the aggregated allocation quantity assigned to the combination of product family to which the material belongs and sales organization to which the customer belongs. On the product side, it is possible to check allocation at the following levels:
l l l l l

Sub-group - Level 3 in the Product Hierarchy [PH3]. Family - Level 4 in the Product Hierarchy [PH4]. Sub-family - Level 5 in the Product Hierarchy [PH5]. Finished product - Level 6 in the Product Hierarchy [PH6]. Product - Level 7 in the Product Hierarchy [PH7].

Understanding GATP
On the customer side, it is possible to check allocation at the following levels:
l l l l l l

Page 12 of 19

Ship-to party - The customer location to which the product will be delivered. Sold-to party - The customer who placed the order. Sales Representative - The Sales Representative 'responsible' for the customer. Sales Manager - The Sales Manager 'responsible' for the customer. Sales Organization - The Sales Organization within which the order is placed. Territory - The territory to which the customer has been assigned.

Which levels are used (for both the material and the customer) is determined by the allocation procedure (q.v.) selected at the time allocation is activated. Example In this example, a Sales Organization may contain five customers, each of whom is assigned an allocation of 10 units. If the allocation is activated at the Sales Organization level, then all orders placed by any of the five customers in this Sales Organization will be checked against a total (initial) allocation quantity of 50 units (5 customers at 10 units per customer). In this example, any of the five customers could order (and consume the allocation of) up to 50 units - as long as the total quantity across all five customers in the Sales Organization does not exceed the total of 50 units. This is summarized in the following diagram:

Figure 4: Consumption of allocation

Allocation procedures
An allocation procedure defines the level at which the allocation quantity will be checked by GATP at order entry time. For example, one allocation procedure could activate checking at the finished product / sold-to party level, whereas another allocation procedure activates checking at

Understanding GATP
the product family / Sales Organization level.

Page 13 of 19

The allocation procedure also effectively defines the scope of the allocation checking. This is achieved through the use of Characteristic Value Combinations (CVCs). For example, if an allocation procedure is used that activates allocation at the finished product / sold-to party level, then for allocation to be checked for a given order there must be a CVC defined in the Demand Planning module of APO for the specific finished product / sold-to party combination specified in the order. If a CVC for this combination does not exist, then the order will not be checked for allocation. XXXX provides many different allocation procedures. These are defined and maintained centrally by XXXXXXXXXXXXXXXXXXXXXX. Each allocation procedure is specific to an APO Planning Area. Currently, APO is configured to include Planning Areas for XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.

GATP at order entry

GATP checks
GATP performs an automatic ATP check at the time an order is entered. This is a dynamic check of inventory levels of the specified product, at the specified supply point (plant), on the planned loading date, against the order quantity. The GATP module will check both availability and allocation (assuming that both of these checks have been activated for the material/plant combination).

Handling GATP issues

If the GATP module determines that there is a problem with either availability or allocation, it will prompt the CSR (XXXXXXXXXXXXXXXXXXXXXXXXXX) to select one of four possible actions to resolve the issue: A. Confirm the order for the amount of product that is actually available (as identified by the GATP module). The order will then be considered complete (that is, it will not remain open for the undelivered quantity). B.
Not all customers will accept multiple ('split' deliveries). Whether or not they do is specified in the Customer Master File Confirm the order for the requested amount, to be supplied in a single record for the customer. This is not delivery once this quantity is fully available (on a future date, as checked by the GATP identified by the GATP module). module, and so this option is presented Confirm the full requested amount, to be delivered in multiple regardless of whether deliveries(7), as additional product becomes available (on multiple the customer will dates, as identified by the GATP module). accept it or not.
(7)

C.

D. Save the order as 'incomplete'. The order is not confirmed to the customer, and no ATP is consumed. The first three of these options are illustrated in the following diagram:

Understanding GATP

Page 14 of 19

Figure 5: Order confirmation options for GATP issues If the CSR saves the order as incomplete (and does not subsequently cancel it), they may be permitted to contact Supply Chain and/or Sales for assistance in resolving the issue. Local business rules, in conjunction with the customer category, will determine whether or not the CSR has this option. Typically, Supply Chain (or Sales) in turn also has a number of options available to them in order to resolve the issue. For availability issues, one option is to use backorder processing (q.v.). For allocation issues, it may be an option to increase the allocation assigned to the customer. For additional information on handling ATP issues, refer to the "Handle GATP Issues Subprocess" of the "Commit Order Process".

How ATP is consumed

Overview
Whenever an order is entered into the system (and confirmed), the order will 'consume' ATP even though the order may not consume physical inventory until later (at the time that the order is shipped). ATP is consumed because the product allocated to the order is no longer available for allocation to subsequent orders that may be entered. The following three scenarios illustrate the different ways in which ATP can be consumed by an order.

Scenario A
An order for 20 units is entered on Day 2, with a planned ship (goods issue) date of Day 5. There are no other scheduled receipts or issues planned for this period.

Understanding GATP

Page 15 of 19

Figure 6: A sales order consuming current inventory In this scenario, the sales order consumes 20 units of ATP from the ship date back to the current date (the date on which the order was entered).

Scenario B
An order for 20 units is entered on Day 2, with a planned ship (goods issue) date of Day 5 (as per Scenario A). There is a planned receipt of 30 units from production, due on Day 3 (which is prior to the ship date of the order). Therefore, planned production is sufficient to meet the requirement.

Figure 7: A sales order consuming planned production In this scenario, the sales order consumes 20 units of ATP from the planned ship date only back as far as the planned production date - and not back to the current date (the date on which the order was entered).

Scenario C
An order for 40 units is entered on Day 2, with a planned ship (goods issue) date of Day 5. There

Understanding GATP

Page 16 of 19

is a planned receipt of 30 units from production, due on Day 3 (which is prior to the ship date of the order). In this case, planned production is not sufficient to meet the full requirement.

Figure 8: A sales order consuming planned production and current inventory In this scenario, the sales order consumes the full 30 units of planned production, but also consumes 10 units of current inventory, back to the current date (the date on which the order was entered). Note that only 10 units of ATP are consumed from Days 2 to 3, and not the full 40 units required.

Backorder processing
Overview
Whenever an order is entered into the system (and confirmed), the order will 'consume' inventory. As a result, the ATP level will go down, as the product allocated to the order is no longer available for allocation to subsequent orders that may be entered. This is described in more detail in "How ATP is consumed", above. Typically, orders will consume inventory in the sequence in which they are entered. This means that if an order is entered today, but is not due to be shipped for another month, then the order will effectively consume the inventory that is available today (ignoring the question of the checking horizon). If another order is subsequently entered for the same product, but for delivery in one week's time, then it could happen that product is not available for allocation to this second order, because the only available product has already been allocated to the first order. This would mean that the second order could not be confirmed (or delivered), even though the product is physically available, and wont actually be needed for another month. Alternatively, production may not actually meet the planned levels against which the ATP check was originally carried out, resulting in an inability to meet demand for all committed orders. Backorder processing provides a way to investigate and resolve these situations.

Running backorder processing

Understanding GATP

Page 17 of 19

'Running Backorder Processing' actually involves generating a report in APO (via transaction \SAPAPO\BOP_WORKLIST). This report lists all of the sales orders that are currently consuming ATP. This report can be generated according to a number of criteria, such as materials and/or dates, and be sorted on (typically) the requested delivery date or the customer category (which is defined as the delivery priority in the Customer Master File). Supply Chain (XXXXXXXXXXXXXXXXXXXXXXXXX) can then review this report to decide upon possible courses of action to resolve (for example) ATP issues with the sales order(s). Typically, the following options are available:
l l l l

Change the order quantity of one or more orders. Change the planned delivery date for one or more orders. Schedule (or reschedule) additional production. Schedule (or reschedule) additional replenishment orders.
(8)

It is important to note that the GATP module itself will not make any changes. The only output from the GATP module is a report suggesting possible options. It is then up to XXXXXXXX and/or XXXXXXXXXXXXX XXXXXXXX to make the required changes in the SAP system, manually.
(8)

Backorder processing will only consider sales orders for which a delivery has not yet been created. (Sales orders for which a delivery has been created are omitted because the basic philosophy of the SAP system is that delivery documents are created as late as possible, so if the delivery document has already been created, then it is probably too late to change the order.) Backorder processing will also not consider Stock Transport Orders.

Standard SAP functionality does provide the option to automatically reschedule orders. However, this functionality has not been enabled for XXXXXXXX.

Backorder processing in action

The following diagrams illustrate one possible application of Backorder Processing. In this case, Backorder Processing is used in conjunction with XXXXXXXXXXXXXXXXXXX (based on the customer category) to identify sales orders that can be re-scheduled. Before backorder processing In this example, an order for Product A (Order A) is entered for a Category D customer and confirmed against existing inventory. There is production scheduled, but this is after the ship date. After this order is entered, another order for the same product (Order B) is entered for a Category A customer. This has a delivery date before the first order, but cannot be confirmed because the first order is consuming most of the ATP for Product A.

Understanding GATP

Page 18 of 19

Figure 9: Sales order blocked because of insufficient ATP After backorder processing Backorder Processing is run, and the report is sorted on the basis of customer category. The report identifies the second order as 'more critical' (because it is for a higher category customer). Because Backorder Processing can't magically make more Product A, something has to change. In this example, it is deemed better to delay the Category D customer by two days, rather than delay the Category A customer by four days (which is what would have happened had Order B been left until additional stock was available). Therefore, the decision is made to move Order A back until after the planned production, and confirm Order B instead. (Note that this is an entirely fictitious example - how Backorder Processing may be used XXXXXXXXXXXXXXXX is decided by the Business.)

Printed: 7/22/04 at 6:52:01 AM

Understanding GATP
Figure 10: Order re-scheduling after Backorder Processing

Page 19 of 19

Effectively, the ATP of Product A is allocated to the second order instead of the first. Note that ATP is not consumed during days 4 to 6 because Order A is being fulfilled from the planned production (see Scenario B under "How ATP is consumed", above). Note that this example shows only one possible outcome of Backorder Processing. Alternative actions could be to move the planned production forward by two days, or to schedule additional replenishment for receipt before Day 5. These two options would allow both orders to be committed for the requested delivery dates. In addition, this scenario describes only one possible use of Backorder Processing - to solve order commitment issues. It is also possible to use Backorder Processing for other purposes for example, when planned production does not materialize. In this case, Backorder Processing could be used to identify the orders that would have been fulfilled by this production, thereby allowing Supply Chain to take appropriate remedial steps. Local business rules will define when, and for what purposes, Backorder Processing can be used.

Related information
Process documents The Commit Order Process The Balance Supply and Demand Process

Document Change History

Vers. Date 1.0 16-JUN-2004 Description of change Original document.

This document is uncontrolled when printed. The latest version can be viewed as an on-line document via the Knowledge Warehouse. Rate this document How useful did you find this document? Not at all... 1 2 3
j k l m n j k l m n i j k l m n

Is this document clear, accurate, and easy to follow? Submit specific suggestions to improve this document.

...very 4 5
j k l m n j k l m n

Submit

This feedback is optional and anonymous. You will not be contacted about your comments.