Multilevel ATP Check

Purpose
There are industry areas (for example, PC assembly) in which a large part of the valueadded activity arises at final assembly. The assemblies on the lower production levels have already been produced or procured before the sales order comes in, but final assembly is only initiated when the sales order arrives. The multilevel ATP check is usually used in these areas, since the components that are required to produce an end product are checked when a sales order is created. A particularly suitable use of the multilevel ATP check is sales order entry for configured products. A sales order can only be accepted when all required components are available. However, the configuration requested by the customer determines which components are needed specifically and this can only be checked at the time of sales order entry. In contrast to Capable-To-Promise (CTP), no receipt elements are created in the SAP APO order network during the multilevel ATP check. Instead, the check results are stored in the ATP tree structure. Receipt elements are only generated later when the ATP tree structure is converted in PP/DS. This allows improved performance during the check. However, statements on capacity availability and component availability can only be rough (on a daily basis) and not as detailed as in CTP (in seconds). As long as no receipt elements exist, the ATP tree structure exists in the SAP APO database. Requirements at component level are represented as aggregated quantity assignments. The ATP tree structure and the aggregated quantity assignments are deleted or reduced directly after the conversion into receipt elements. The multilevel ATP check supports the following functions: Scope of check in the product availability check for components Product allocation at finished product level Checking against the forecast at component level Mapping of capacities using product allocations Exclusion of specific components from the check (that is, complete confirmation of the components without check) Return of data by means of the components/characteristic values that have led to a delay or reduction of the confirmation (missing parts list) Rules-based ATP check at component level, whereby a location determination generates a stock transport requisition in PP/DS. For more information, see Rules-Based ATP Check at Component Level.

 Cross-system third-party order processing at finished product level, together with multilevel ATP check

Prerequisites
The OLTP system connected to SAP APO can be an ERP system, an SAP CRM, or a non-SAP system. A production process model (PPM) must be created in SAP APO. The master data of the components must be created in SAP APO. The multilevel ATP check only takes into account the components that are created in SAP APO. You created a production calendar in the location master for scheduling You entered a check mode and an ATP group in the location-specific product master data for the component (ATP tab page). As with substitutions for the rules-based ATP check, the system must read the check mode and the ATP group in the product master, so that the check instructions and the check control can be determined for the ATP check of the component. For more information, see Maintaining Location-Dependent Product Master Data. You configured the multilevel ATP check in the check mode for the finished product. If you want a multilevel plan explosion and multilevel ATP check to be carried out using dependent BOMs, the multilevel ATP check must be configured in the check mode for the component that is simultaneously the header material of a BOM.

The plan explosion and ATP check for further dependent BOMs can also be achieved if a rules-based ATP check, which calls production for substituted components that are simultaneously header materials of BOMs, is carried out at component level. The multilevel ATP check must be configured in the check mode for the substituted components. In SAP APO Customizing, choose Global Available-to-Promise (Global ATP) General Settings Maintain Check Mode.

Existing requirements classes, for which sales orders already exist, should not be changed in the ERP system. If you implement the multilevel ATP check, you should create your own requirements class. For more information, see Controlling the ATP Check for Components. You have made the following settings in the check instructions for the ATP check: In the check instructions for the ATP check of the finished product and the components, which are header materials of the dependent BOMs, you have configured the trigger, the time of production, and the creation of a remaining requirement for the components (see also Multilevel ATP Check in Two Steps). In the check instructions for the ATP check of the finished product or (for the rulesbased ATP check) the product substitution, you have also configured the conversion mode for the ATP tree structure. In the check instructions of the finished product to be checked, you have set the Recreate rcpts (recreate receipt elements) indicator. This ensures that during the next ATP check of the sales order you have already saved, the system replaces the existing receipt elements with new, more suitable receipt elements. In addition, you can enter your own business event for the multilevel ATP check in the check instructions for the finished product and the component, which is also the header material of a BOM. You do this if you want the check instructions and the check control for the ATP check of the components to be distinguished from the check control for the ATP check of the finished product/header material. If you have not entered a specific business event for the components in the check instructions, the system uses the business event for the check at finished product level or header level. In SAP APO Customizing, choose Global Available-to-Promise (Global ATP) General Settings Maintain Check Instructions. You included the category AY (dependent requirement) in the scope of check for the ATP check at component level. In Customizing of SAP Advanced Planning and Optimization (SAP APO), choose Global Available-to-Promise (Global ATP Check) Product Availability Check Maintain Check Control. If you implement the rules-based ATP check for components, you can use a specific business transaction for determining a rule strategy in Customizing for SAP APO, by choosing Global Available-to-Promise (Global ATP) Rules-Based Availability Check Create Business Transaction for Multilevel ATP Check. For more information, see Rules-Based ATP Check at Component Level. You have created a PP/DS horizon for the products and components in the location product master. If you have not entered one there, the system uses the PP/DS horizon of the planning version. You have created a scheduling horizon for the multilevel ATP check. As a rule, this is smaller than or the same size as the PP/DS horizon. You create the scheduling horizon for

the multilevel ATP check in Customizing for the SAP Advanced Planning and Optimization (SAP APO) under Supply Chain Planning Production Planning and Detailed Scheduling (PP/DS) Global Settings Maintain Global Parameters and Defaults.

Process Flow
... 1. You create a sales order in the ERP system, for example, for a finished product for which a production process model has been maintained in SAP APO. A strategy group, for example, that determines a requirements class using the requirements type, is assigned to the material. This requirements class corresponds in SAP APO to a check mode that allows a multilevel ATP check. For more information on sales order processing in the ERP system, see

Sales SD-SLS. 2. In the ERP system, an ATP check, which is performed in SAP APO, is triggered automatically. The check instructions determine the progress of the ATP check in SAP APO. In this example, you configured that an ATP check is carried out first and then production is called (it is also possible for a multilevel ATP check to be triggered immediately). Through the ATP check, the (partial) quantities at finished product level that can be confirmed are protected from concurrent requests by a temporary quantity assignment. For more information, see Basic Methods of the Availability Check. 3. If the requirements quantity cannot be confirmed completely, a multilevel ATP check is carried out. The multilevel ATP check is carried out in two steps if the requirements quantity cannot be confirmed completely for the requested date and there are, therefore, partial confirmation quantities and dates. In PP/DS, a source determination, plan explosion, and scheduling are triggered. For more information, see Source Determination in PP/DS and Determining the Component Quantities and Requirements Dates for the Multilevel ATP Check. For the component requirements created, an ATP check is carried out according to the check instructions configured for the components. For more information, see Controlling the ATP Check for Components. If a component is not available in sufficient quantity, this process is carried out on a

multilevel basis, if necessary, provided a PPM exists for the lower-level components. The confirmations are correlated afterwards. The availability of the finished product results from the availability of the components. If the multilevel ATP check can confirm the requirements quantity for the requested date, a second step is not carried out, since the result of the multilevel ATP check is exactly one date and one quantity, for which a receipt element can be created in PP/DS. It behaves differently if the result of the multilevel ATP check consists of confirmed partial quantities and dates. In this case, the second step of the multilevel ATP check is carried out. The setting in the conversion mode for the ATP tree structure controls which confirmed (partial) quantities and dates are included as requirements quantity and requirements date in the second step of the multilevel ATP check. There is another plan explosion and scheduling again in PP/DS and an ATP check is carried out for the component requirements. The complete requirements quantity must now be confirmed at header level for the requirements date. If there is no confirmation (because of violated validities), the system deals with the unconfirmed quantity, depending on the CompRemainReqmt setting in the check instructions. The remaining requirement can be created at header level or component level. For more information, see Multilevel ATP Check in Two Steps. Prepersistent temporary quantity assignments are written for the component requirements. For more information, see persistency indicator. A results overview is displayed. The component requirements and confirmations are shown in a hierarchical display (see also Results Overview). The total confirmation for the finished product and the confirmation for the component requirements are displayed there. The confirmation for the components cannot be changed. 4. You transfer the result. The confirmations for the components are not transferred to the ERP system. 5. The sales order in the ERP system contains a confirmed quantity and a date for the finished product. 6. You save the sales order in the ERP system. 7. In SAP APO, an ATP tree structure is saved to the SAP APO database. Depending on the scheduling horizon and PP/DS horizon, the ATP tree structure is converted immediately when the sales order is saved and a procurement proposal is created in PP/DS. If the scheduling horizon and PP/DS horizon chosen are too small, the ATP tree structure is only saved persistently to the SAP APO database at first. In this case, a conversion must be made later in PP/DS. In SAP APO, the temporary quantity assignment is deleted and a requirement is generated for the finished product in SAP liveCache. At the same time, the ATP tree structure is saved persistently to the database. Component requirements are stored as aggregated quantity assignments. For more information, see ATP Tree Structures.

Depending on the scheduling horizon and the PP/DS horizon, a receipt element can be created immediately in PP/DS when the sales order is saved. In this case, the value (days) chosen in the scheduling horizon for the multilevel ATP check must be large enough so that the ATP tree structure can be converted immediately (and then deleted) and so that a procurement proposal can be generated automatically. The ATP tree structure is always converted per request schedule line of the sales order. For more information, see Converting ATP Tree Structures. You configure the scheduling horizon for the multilevel ATP check in Customizing for SAP APO under Supply Chain Planning Production Planning and Detailed Scheduling (PP/DS) Global Settings Maintain Global Parameters and Defaults (Planning tab page). If the ATP check has established that the validity of a BOM has been violated with regard to the date or the quantity, an alert is generated in the Alert Monitor when the sales order is saved. If the BOM validity has been violated within a delivery group correlation or a change in the delivery proposal screen at finished product level, the sales processor can implement backorder processing (selection of orders using alerts). Furthermore, an alert is generated in the Alert Monitor when the sales order is saved if a planned order has been checked, but generated unconfirmed in PP/DS or is generated in a later conversion of the ATP tree structure. This is the case if you have configured the creation of a remaining requirement at component level in the check instructions. The planner must make sure that the unconfirmed components are procured. For more information, see Alert Monitor. 8. If the ATP tree structure was not converted immediately when the sales order was saved, you must convert the ATP tree structure later in PP/DS. The ATP tree structure and the aggregated quantity assignments are deleted or reduced directly after the conversion. For more information, see Converting the ATP Tree Structure into a Receipt Element in PP/DS. 9. The planned order or purchase requisition is converted in the ERP system into a manufacturing order or purchase order. For more information, see Transferring Orders to the OLTP System.

Subprocesses
New ATP check when creating or changing the sales order

You usually change the sales order if the requested delivery quantity or the requested delivery date has changed on the customers side. When the sales order is changed, a new ATP check is triggered automatically. Note the following: As long as no receipt elements have yet been created by the system as the result of the multilevel ATP check, you can easily carry out a further ATP check. If the ATP tree structures have already been converted and the system has therefore already created receipt elements, you must note the following when you perform a subsequent ATP check: If you set the Re-create rcpts (recreate receipt elements) indicator in the check instructions of the finished product, the system can create a more suitable receipt element during a subsequent ATP check. The system adjusts the receipt elements on a multi-level basis in the entire order structure and deletes the previous, superfluous receipt elements. For more information, see Recreation of Procurement Proposals. If you did not set the Re-create rcpts (recreate receipt elements) indicator in the check instructions of the finished product, the following three cases are possible: Requested quantity is increased; requested delivery date is shifted into the future The system carries out a new ATP check for the requested quantity. The receipt elements created until now are taken into account in the scope of check of the ATP check. For the quantity that is now still open, the system will carry out a multilevel ATP check, if necessary. If the requested delivery date is shifted into the future, the system can confirm the result in a new ATP check, since the requirement quantity has already been confirmed for an earlier requested delivery date.

In this case, direct production may not be configured, since production is then called directly without an ATP check being carried out beforehand. Requested quantity is reduced; requested delivery date is shifted into the past The system carries out a new ATP check for the requested quantity. The receipt elements created until now are taken into account in the scope of check of the ATP check. The system can confirm the requested quantity. However, planned orders now exist that are not actually required.

If the requested delivery date has been shifted into the past, the ATP check will not be able to confirm the requirement quantity by the requested delivery date. The system carries out a new multilevel ATP check. If the ATP tree structure is converted, planned orders now exist that are not required. Production directly In this case, production is always called immediately and a new multilevel ATP check is carried out. After the ATP tree structure is converted, planned orders exist that are actually not required. Direct production only makes sense in the following cases: As part of a rules-based ATP check When the receipt elements can be deleted automatically (see below)
Mapping of capacities using product allocations

If capacities should be checked during the multilevel ATP check, you can define this using a preceding check against product allocations. Only product and location are allowed characteristics. This is a restricted check against product allocations that does not support characteristics such as sold-to party. Since the system only uses the SAP APO information in an ATP check of components, some information is missing, such as the field catalog that is normally transferred from the ERP system and that is only available to the finished product in SAP APO when there is a multilevel ATP check. For this reason, the characteristics RULE_MATNR and RULE_WERKS are the only characteristics allowed that you can use in the product allocation group for the check against product allocations at component level. You can find these characteristics in the search help for the field catalog enhancement in the IMG activity Maintain Product Allocation Group. Note that no automatic synchronization is made between the product allocations and the resources/resource assignments. If, for example, a resource is no longer available or a planned order is changed manually, the product allocations must be adjusted manually, if necessary. For more information, see Product Allocation Settings.
Display

The multilevel ATP check results are shown in the results overview. Depending on the progress of the check, a missing parts list, among other things, can be issued dynamically. For more information, see Results Overview.

Constraints
The multilevel ATP check does not take any lot sizes into account; in other words, only the lot-for-lot order quantities are taken into account. Order quantities are adopted from

ATP. An order split or an order combination is only possible manually in PP/DS and only then if neither configuration nor product substitutions exist. You can only correct incorrect component validities manually in PP/DS (delete order, recreate order, and execute new multilevel ATP check). You can define that an alert should be created in such a situation. If the configuration model is changed, the sales order is not updated. Similarly, if there are changes to the plan, the planned orders and production orders are not adjusted either. There is no automatic synchronization of resources/resource assignments and product allocations. Resources can only be checked during the ATP check in the form of product allocations. There is no tool for leveling capacities and product allocations. The product allocations can possibly be determined with the help of DP/SNP. The user is responsible for the consistency of SNP PPMs and PP/DS PPMs or runtime object. If a configuration is being used, the configuration model and substitutions possible at component level using the rules-based ATP check must be maintained consistently. If you are working at finished product level with configuration and a product substitution is carried out at component level, this neither leads to a new configuration, nor to another product at finished product level. When there is a stock transfer using the rules-based ATP check no simultaneous product substitution should be made. Within a multilevel ATP check, product allocation is only possible for components in a limited way. At component level the check against product allocations is only used to represent a type of capacity check. Combinations of multilevel ATP check and Capable-to-Promise (CTP) are not supported; in other words, per BOM, either only a multilevel ATP check or only CTP can be carried out. The activated Re-create rcpts (recreate receipt elements) indicator only has an effect for make-to-order production or when the sales order is pegged to the requirement. Only those receipt elements that allow a deletion are deleted. In other words, if the planned order transferred from SAP APO is fixed once at header level in the ERP system, this function cannot be used. A characteristics-based check at stock level (production type characteristic evaluation in the check mode) is not possible for components. Multilevel configuration is currently only possible with iBASE, but not with CDP. The reason for this is that the CDP characteristic value assignments are stored in SAP liveCache and a carrier of this value assignment must therefore exist there. In the multilevel ATP check this is not the case at component level, however, if no planning has yet been carried out. If the CDP characteristic value assignments are stored in the SAP APO database, multilevel configuration should be possible for CDP characteristics too.

 Phantom assemblies are not known in ATP. In particular, no checks and no rules-based ATP check can be carried out for phantom assemblies. A characteristics-based ATP check at component level is not supported. The determination of the source characteristic value assignment for a late component is only possible in the following cases: iPPE: There is a 1:1 assignment between characteristic value and component. If a component is determined through n characteristics, these can only have an AND relationship and not an OR relationship. In addition, the following must apply: A characteristic corresponds to a characteristic value. A combination of characteristics is not permitted. CDP: Characteristic value assignments are only copied within a plan by means of characteristic propagation, but not derived using macros. Manufacture of co-products is not supported. If a document is checked that refers to another document (for example, sales order refers to a quotation or a delivery refers to a sales order), no ATP tree structure exists any more for the referenced document at the time of the subsequent document. In other words: A multilevel ATP check can be carried out for quotations, but the items of the quotation for which a multilevel ATP check is carried out, must not be requirementrelevant (in this case no ATP tree structure is written). If a delivery, which refers to a sales order for which a multilevel ATP check has been carried out, is checked, a planning run must have already been carried out for the referenced order items, so that no ATP tree structure exists for them any longer. A rules-based ATP check with stock transfers is only possible if both locations involved are in the same OLTP system. Conservative delta handling is not possible. The super BOM is not exploded. The ATP check only works exactly with the configuration/characteristic value assignment that has been transferred from the caller to the check. Only those characteristics that are evaluated uniquely are relevant. The multilevel ATP check only works in the active planning version. In order that the planning run can create stock transport requisitions, a transportation lane must be maintained between the relevant locations. See also: Rules-Based ATP Check at Component Level Locking Concept