Availability Check and Transfer of Requirements Depending on the system configuration, the SAP System can check availability for every item in a sales document or delivery. Furthermore, it creates MRP records and passes them on to materials planning. planning. The availability check is carried out at plant level.
Control elements in Customizing In addition to other settings, the following control elements are of particular significance in SD-Customizing: y
y
y
In general, the requirements class determines the requirements classes for which the availability check and/or transfer of requirements should be carried out. The global settings at requirements class level can be differentiated at schedule line level. The checking group determines the standard replenishment lead time and (together with the MRP group) the type of requirement records (e.g. individual records, summarized records per day) to be created. Checking rule The checking rule determines the scope of the availability check and whether or not the replenishment lead time should be taken into account.
The MRP groups are defined in materials planning in PP Customizing. y
y
The system uses the MRP group to determine the relevant requirements type for a transaction. The requirements type defines whether the transfer of requirements or availability check should be carried out for the respective transaction. The MRP groups must be defined in collaboration with SD. In Release 3.0, you can enter the strategy group directly into the material master record. It is usually determined using the MRP group.
Note
The control of the check's scope and the type of requirements records are interdependent.
Specifications in the material master record You make two particularly significant specifications in the material master record for the availability check and transfer of requirements: y
y
y
Checking group (material master record: Sales/plant data or MRP 2): basically defines whether the availability check should be carried out for a particular material and the type of requirements record to be created. MRP group (material master record: MRP 1): the system uses this group to determine the requirements type relevant for a transaction. Strategy group: is an alternative to determining requirements using the MRP group. You can maintain this group directly in the material master record.
The following further control elements in the material master record can also influence the result of the availability check:
y
Planned delivery (MRP 1)
y
GR processing time (MRP 1)
y
Total replenishment lead time (MRP 2)
Further possibilities for controlling the availability check and
transfer of requirements
The availability check and transfer of requirements can in principle be controlled independently of one another. When you create a sales document, the transfer of requirements and availability check can be carried out independently. The way in which these are controlled is dependent on th requirements class and schedule line category.. category When you create a delivery, the availability check can only be carried out in combination with the transfer of requirements. Requirements, however, can be transferred without the availability check being carried out. These control elements apply to sales documents and deliveries alike. The procedure and scope of the check can, however, be controlled separately for sales documents and deliveries, so that a different type of availability check is carried out in delivery processing as in sales order processing, for example. In sales documents, you can block order quantity confirmation (for certain delivery blocks), for instance. Further
literature 1. For a detailed description of the availability check and transfer of requirements from the point of view of the user, see the SD Sales and SD Shipping manuals. 2. The PP Master Planning/MRP Guide describes the determination of the requirements type. 3. For further information on the MRP group, see IMG step "Planning strategy" for materials planning. The MRP groups are configured under the menu option " Master data" data " in materials planning in Production. Requirements type determination is also to be found here.
Availability Check The following sections describe configurations for the availability check. check. For every item of a sales order or delivery, the SAP system checks availability if the appropriate configuration is set in sales order processing and shipping. The availability check procedure depends on several factors and varies according to the configuration. It is possible to control the availability check for sales documents and deliveries separately. You can, for example, control the scope of the checks or whether the replenishment lead time is taken into account, for example. The availability check is controlled by means of the same elements as the transfer of requirements: y
Requirements class
y
Requirements type
y
Checking group
y
Checking rule
y
Schedule line category
y
Strategy group
y
Planning strategy
For more information on strategy groups and planning strategy, see the 'Planning strategy' chapter under Production Planning in the Implementation Guide. Requirements Process the following points to control the availability check: 1. For the sales document types you must determine for each schedule line type whether an availability check should be carried out or not. 2. The availability check should be switched on at requirements class level and at schedule line level for sales documents. 3. You can define a checking group which can be proposed, depending on the material type, when a new material master record is created. 4. The requirements types used must each be allocated to a requirements class. 5. Note that a plant must be available if an availability check is to be carried out at document item level.
Definition: availability check Materials Management (MM) A stock check that is run automatically after each goods movement and which is intended to prevent the book inventory balances of physical stock categories (such as unrestricted-use stock) from becoming negative.
Material Requirements Planning (PP-MRP) A procedure that ensures that there are enough components available for planned or production orders in production planning and production control.
Definition: sales document S ales ales
and Distribution ( S SD) D )
A database document that represents a business transaction in the sales department. A sales document consists of a document header with data applicable to the whole document, as well as any number of document items, with data regarding goods or services required by the customer. Types of sales document types include: y
Inquiry
y
Quotation
y
Sales order
y
Outline agreement (contracts and scheduling agreements)
y
Complaints (returns, credit memo requests and debit memo requests)
Definition: replenishment lead time Material Requirements Planning (PP-MRP) The total time for the in-house production or for the external procurement of a product. In in-house production, the replenishment lead time is determined to cover all BOM levels.
Definition: requirements type Personnel Time Management (PT) A representation of staffing requirements on the calendar. Examples
y
Requirements on weekdays
y
Requirements on Easter Monday
y
Requirements on Mondays
Production Planning (PP-MP) The classification of independent requirements types into, for example, customer requirements, planned independent requirements, or warehouse requirements.
Define Checking Groups In this IMG section you define checking groups with which you specify the type of requirements records the system is to create when processing sales orders or deliveries. Sales order requirements and delivery requirements can be controlled separately. You can create the following requirements records: y
Individual requirements records In individual requirements records, a requirement is created for each SD document. The respective entry in the stock/ requirements overview identifies the order quantity and the document which gave rise to the requirement.
y
Summarized requirements records Summarized requirements records group together or update several requirements under certain conditions in the material master record (plant, date, procedure, requirement class). There are two types of summarized requirements records: o
Summarized requirements records for each day
o
Summarized requirements records for each week
Monday of the current week or Monday of the following week is regarded as a requirement date. Availability check taking cumulated confirmed quantity into account If confirmed quantities are not cumulated, the following problem may occur: Starting from the delivery date of the sales order and working backwards, the system checks whether ATP quantities exist. If such quantities do exist, the new sales order will reduce these ATP quantities. Here, sales orders can only reduce the ATP quantities if they lie before the delivery date. In this logic, the system does not take the confirmed quantity of sales orders that have already been created into account. If, in the past, receipts were either moved forward or backward and/or they were reduced, it is possible that the ATP quantity of the receipt that lies directly before a sales order which has already been confirmed is no longer sufficient to cover the requirement. The following example should clarify this point: MRP elemt
Recpt/Reqmt ATP qty Cumul. ATPqty Confirmed qty
Stock
100
0
0
-
SALES ORD 1 -200
-100
-100
-200
PLND ORD
0
0
-
0
0
100
100
SALES ORD 2 -100
In this example, the first sales order was completely confirmed when the planned order lay before sales order 1 on the time axis. Then, the planned order was rescheduled out so that it now lies after the delivery date of sales order 1 on the time axis. For the new sales order 2, the ATP check comes up with an ATP quantity of 100 as the rescheduled planned order is now completely available again and according to the ATP logic, sales order 1 cannot be covered by this receipt. In this particular example, the confirmation situation is no longer up-to-date as the planned order has been rescheduled. Therefore, the sum of all the confirmed quantities exceeds the sum of all receipts. To solve this problem, you have the following options: y
carry out the planning run
y
reschedule
y
carry out backorder processing
With the cumulation of quantities, you can avoid such inconsistencies as you can control exactly how the system is to carry out the check: y
Availability check taking cumulated confirmed quantity into account
When creating/changing a new sales order, the system includes all the quantities confirmed to date when calculating the cumulated ATP quantity. This means that the new sales orders can only be confirmed if the sum of the receipts exceeds the sum of the confirmed quantities. y
Availability check taking cumulated requirements quantities into account
When creating/changing a new sales order, the system includes the sum of all open requirements quantities when calculating the cumulated ATP quantity. This means that new sales orders can only be confirmed if the sum of the receipts exceeds the sum of the requirements quantities. You can make the following settings for this new ATP checking logic when creating/changing a sales order: y
cumulate the confirmed quantities when creating and changing
y
cumulate the requirements quantity when creating, no cumulation when only making changes
y
y
cumulate the requirements quantity when creating and cumulate the confirmed quantity when making changes no cumulation (old checking logic)
Determining the checking group The checking group is determined depending on the material type and plant and is proposed in the material master record. The section "Define the checking group for each material type" describes how to allocate checking group to material type and plant. Together with the checking rule, the checking group determines the scope of the availability check. Note
For procedures relevant to requirements which lead to special stock (e.g. make-to-order production), the system automatically creates individual requirements records, even if the configuration was set in the material master record or via the checking group for summarized requirements records. Warning
You can use either summarized requirements or individual requirements for each checking group. Changing the method of summing up requirements results in a change in the information contained in the record. When you change from individual to summarized requirements, you lose the assignment to sales orders, for example. Actions 1. Check to what extent you can use the configurations set for the checking groups in the standard version of the SAP System.
AVAILABILITY CHECK Define checking group
WITH
ATP LOGIC OR AGAINST PLANNING
Define Checking Groups In this IMG section you define checking groups with which you specify the type of requirements records the system is to create when processing sales orders or deliveries. Sales order requirements and delivery requirements can be controlled separately. You can create the following requirements records:
y
Individual requirements records In individual requirements records, a requirement is created for each SD document. The respective entry in the stock/ requirements overview identifies the order quantity and the document which gave rise to the requirement.
y
Summarized requirements records Summarized requirements records group together or update several requirements under certain conditions in the material master record (plant, date, procedure, requirement class). There are two types of summarized requirements records: o
Summarized requirements records for each day
o
Summarized requirements records for each week
Monday of the current week or Monday of the following week is regarded as a requirement date. Availability check taking cumulated confirmed quantity into account If confirmed quantities are not cumulated, the following problem may occur: Starting from the delivery date of the sales order and working backwards, the system checks whether ATP quantities exist. If such quantities do exist, the new sales order will reduce these ATP quantities. Here, sales orders can only reduce the ATP quantities if they lie before the delivery date. In this logic, the system does not take the confirmed quantity of sales orders that have already been created into account. If, in the past, receipts were either moved forward or backward and/or they were reduced, it is possible that the ATP quantity of the receipt that lies directly before a sales order which has already been confirmed is no longer sufficient to cover the requirement. The following example should clarify this point: MRP elemt
Recpt/Reqmt ATP qty Cumul. ATPqty Confirmed qty
Stock
100
0
0
-
SALES ORD 1 -200
-100
-100
-200
PLND ORD
0
0
-
0
0
100
100
SALES ORD 2 -100
In this example, the first sales order was completely confirmed when the planned order lay before sales order 1 on the time axis. Then, the planned order was rescheduled out so that it now lies after the delivery date of sales order 1 on the time axis. For the new sales order 2, the ATP check comes up with an ATP quantity of 100 as the rescheduled planned order is now completely available again and according to the ATP logic, sales order 1 cannot be covered by this receipt. In this particular example, the confirmation situation is no longer up-to-date as the planned order has been rescheduled. Therefore, the sum of all the confirmed quantities exceeds the sum of all receipts.
To solve this problem, you have the following options: y
carry out the planning run
y
reschedule
y
carry out backorder processing
With the cumulation of quantities, you can avoid such inconsistencies as you can control exactly how the system is to carry out the check: y
Availability check taking cumulated confirmed quantity into account
When creating/changing a new sales order, the system includes all the quantities confirmed to date when calculating the cumulated ATP quantity. This means that the new sales orders can only be confirmed if the sum of the receipts exceeds the sum of the confirmed quantities. y
Availability check taking cumulated requirements quantities into account
When creating/changing a new sales order, the system includes the sum of all open requirements quantities when calculating the cumulated ATP quantity. This means that new sales orders can only be confirmed if the sum of the receipts e xceeds the sum of the requirements quantities. You can make the following settings for this new ATP checking logic when creating/changing a sales order: y
cumulate the confirmed quantities when creating and changing
y
cumulate the requirements quantity when creating, no cumulation when only making changes
y
y
cumulate the requirements quantity when creating and cumulate the confirmed quantity when making changes non cumulation (old checking logic)
Determining the checking group The checking group is determined depending on the material type and plant and is proposed in the material master record. The section "Define the checking group for each material t ype" describes how to allocate checking group to material type and plant. Together with the checking rule, the checking group determines the scope of the availability check. Note
For procedures relevant to requirements which lead to special stock (e.g. make-to-order production), the system automatically creates individual requirements records, even if the configuration was set in the material master record or via the checking group for summarized requirements records. Warning
You can use either summarized requirements or individual requirements for each checking group. Changing the method of summing up requirements results in a change in the information contained in the record. When you change from individual to summarized requirements, you lose the assignment to sales orders, for example. Actions
1. Check to what extent you can use the configurations set for the checking groups in the standard version of the SAP System. 2. Enter the method of summing up for each checking group when creating a sales order document or a delivery. 3. If necessary, activate the cumulation of confirmed quantities.
Define material block for other user
Define Material Block For Other Users In this IMG activity you define for each checking group and initiator whether the material master record should be blocked for other orders during the availability check. If it is blocked, you cannot create two orders for the same material at the same time. Using the Initiator field you can define the block separately for sales and shipping. Example
A block may, for example, be necessary if the material stock is low. In theory, if the material were not blocked during the availability check, two orders could be confirmed with the result that the quantity available is not sufficient for both orders.
Note
You cannot yet change the values for the field "Initiator of the availability check" (sales order, delivery note) in the configuration menu. Actions 1. If appropriate, set a block for the combinations of checking group and initiator. Specify whether this is relevant for Sales or Shipping.
Define Checking Groups default value
Carry out control For Availability Check
Define Checking Groups Default Value In this IMG activity, you define the checking group that the system proposes when you create a new material master record. You can overwrite the default value for the checking group in the material master record. The default value depends on the material type and plant. The SAP R/3 System copies this value to the SD documents, thereby proposing a certain extent of the availability check. Requirements You have defined your material types and plants. Actions 1. Make sure that the system proposes the checking groups you require for the availability check in the material master (under sales: general/plant data). 2. Check which checking groups are to be valid for which material types in the different plants. 3. Assign a default checking group to the material types in the individual plants. You can enter a default value for each material type. For a definition of checking groups, see the IMG activity Define checking groups. 4. Make sure that the availability check indicator is maintained in the material master.
Carry Out Control For Availability Check In this IMG step, you define checking rules for the availability check and allocate them to a checking group. The checking rule specifies the scope of the availability check for the respective transactions in sales and distribution by specifying precisely which stocks, receipt and issue elements should be taken into account during the availability check. Every checking rule is allocated to a checking group: together these two elements determine the final inspection requirements. In addition, the checking rule includes a specification whether or not an availability check should take into account the replenishment lead time. Currently, the checking rule is predefined in SD. When specifying the inspection scope for a certain checking rule, you can currently select the following receipts and issues: y
purchase orders
y
production orders
y
purchase requisitions
y
planned orders
y
dependent requirements
y
reservations
y
dependent reservations
y
sales requirements
y
delivery requirements
SD requirements (= sales requirements and delivery requirements) reduce an available stock or inward stock movement on the material availability date so that other issues cannot access the reserved quantity. When specifying the inspection scope for a certain check rule, you can currently select the following stock elements: y
Safety stock (to be maintained in material master record, MRP data)
y
Stock in transfer in the receiving plant
y
Stock in quality inspection
y
Blocked stock
Replenishment lead time The replenishment lead time specifies the time which is needed to order or produce a certain material. The system determines the replenishment lead time as follows: y
y
For internally procured materials the replenishment lead time is determined from the in-house production time and the goods receipt processing time or alternatively from the total replenishment lead time, if it is specified. For externally procured materials the replenishment lead time is determined from the goods receipt processing time and the processing time for purchasing.
In this IMG step, you control whether or not the replenishment lead time should always be taken into account. If you select the field, the replenishment lead time will NOT be taken into account during the availability check. If the field remains unselected, the replenishment lead time will automatically be included in the availability check. If you carry out the availability check using the replenishment lead time, you should plan ahead in regular intervals (on a daily basis for individual and daily requirements, on a weekly basis for weekly requirements) to prevent a shortage and therefore a possible delivery block. This shortage could occur if the delivery date of a sales order, which was confirmed the previous day for the replenishment lead time, is already within the replenishment period on the current day and therefore results in a shortage. Note
For transactions which create individual stocks, such as production-to- order, consignment stock processing or returnable packaging processing, the availability check is carried out for the individual stock depending on the respective special stock indicator.
Actions 1. Check the configurations for the checking groups which are contained in the standard SAP R/3 System. 2. Make sure that the checking group is maintained in the material master records. Depending on the plant, you can specify a checking group for each material type (see section "Specifying a checking group for each material type"). 3. Select the individual stock elements as well as the receipts and issues which should be taken into account during the availability check. 4. Select the field for replenishment lead time if you do NOT want to take the replenishment lead time into account. 5. If your release was updated after 2.0, you must check the indicators for sales and delivery requirements. Before, these sales requirements had to be maintained in a joint field and were first subdivided into two separate fields for Release 2.1. In the release update, a selected original field led to sales and delivery requirements being selected, an unselected field leads to unselected fields in the conversion program.
Define procedure by requirement class
Define Procedure By Requirements Class In this IMG activity you define for each requirements class whether an availability check and/or transfer or requirements should be carried out. The settings defined here correspond to the requirements class settings at a global level. The settings are automatically copied into the definition of the requirements class and vice versa.
Actions 1. Check the extent to which you can copy the settings for the requirements class which are defined in the standard version of the SAP R/3 System. 2. If necessary, change the standard settings by indicating for each requirements class whether an availability check and/or transfer or requirements should be carried out.
Define Procedure for each schedule line category
Define Procedure For Each Schedule Line Category In this IMG step, you specify for the respective schedule line categories of the sales documents whether an availability check and/or transfer of requirements should be carried out. These configurations are only relevant for the sales documents. The fine tuning of the availability check for sales documents that you carry out here depends on their global configuration at requirements class level: You can only deactivate an option selected at requirements class level, but you cannot activate it. You can only activate an an option if it is already activated at requirements class level. Example
You want to implement an availability check without transfer of requirements for sales information. At requirements class level, the availability check and the transfer of requirements must be active. You therefore deactivate the transfer of requirements in the corresponding schedule line category. Requirements The schedule line categories must already have been defined (see section Defining and allocating schedule line categories). The defined schedule line categories are automatically displayed for maintaining.
Actions 1. Specify for each schedule line category whether an availability check and/or a transfer of requirements should be carried out. Keep in mind that the configuration that you set depends on the global configurations at requirements class level.
DETERMINE PROCEDURE FOR EACH DELIVERY ITEM CATEGORY
Determine Procedure For Each Delivery Item Category In this step, you can switch off the availability check for particular item categories in deliveries. The availability check should be switched off for transactions such as returns delivery.
CHECKING RULE FOR UPDATING BACKORDER
Checking Rule For Updating Backorders In this IMG step, you assign a checking rule to a plant. The checking rule specifies for the individual applications the checking rule according to which the availability check is carried out. The checking rule is described in the section "Carry out control of the availability check" . Note
The checking rule entered here is used in production planning. During backorder processing (CO06) and the availability overview (CO09), you should make sure that you are not using any checking rules that deviate from the SD configurations (checking rule A for orders and checking rule B for deliveries). Actions Specify a checking rule for each plant.
DEFINE DEFAULT SETTINGS For SALES AREA
Define Default Settings In this menu option, you specify certain defaults for the availability check. For each sales area which is a combination of sales organization, distribution channel and division, you can set an indicator for fixing the date and quantity as well as a rule for transferring the results of the availability check. y
Fixed date and quantity In this field, you specify for a sales area whether the delivery dates and delivery quantities confirmed after an availability check should be set.
y
Rule for transferring the availability results In this field, you can specify the system response to shortage for a sales area. The following responses are possible: o
The system displays the different options (for example, one-time delivery, full delivery) for selection in a dialog box.
o
The system automatically chooses an option (for example, confirmation of a delivery proposal).
Actions 1. Specify for each sales area whether you want to fix the date and the quantity. 2. Specify for each sales area whether a system response should be issued if the availability check shows a shortage, and if so which.
AVAILABILTY CHECK AGAINST PRODUCT ALLCOATION
Availability Check Against Product Allocation As of Release 3.0E, you can form product allocations that allow you to allocate and control goods in short supply early on. During order processing, an availability check can be carried out against product allocations. The result of this check informs you whether an order requirement can be confirmed according to the products allocated to the customer. This means that the order confirmation is no longer only important for order entries but also for the divided product allocations. If an ATP (available to promise) check is carried out during order entry, a product allocation check is also carried out using the confirmed quantity from the ATP check. If an ATP check is not carried out, the product allocations are checked using the order requirement. In Logistics-Controlling, product allocations are stored in the planning hierarchy at different levels, according to various criteria (Logistics -> Logist. controlling -> Flexible planning -> Planning create/change) . The planning hierarchy is based on the info structure defined in Customizing for the LIS (Logistics General -> Logistics Information System -> Reporting -> Standard Analyses -> Change settings) . Requirements To carry out the availability check against product allocations, the following preconditions must be met: y
y
A product allocation determination procedure must be entered in the material master Statistics update Product allocations are planned in Sales and Operations Planning (SOP) and this planning is based on an info structure. In order to be able to plan product allocations you must make the settings in the Logistics Information System (LIS) Customizing for statistics update in the info structure. This is required at customer, material, header and item levels. The update group must also be maintained in Customizing for the LIS The following steps are necessary: o
Check the following settings and maintain them if necessary: Maintain customer statistics groups Maintain material statistics groups Assign statistics groups by sales document type Assign statistics groups by sales document item category Assign update group at item level Assign update group at header level
o
Activate the update of the SAP standard info structure S140 or a self-defined info structure. The info structures are maintained in Customizing for the LIS.
o
Check the update rules and mantain them, if necessary. The confirmed quantity of the schedule line at the delivery deadline is updated to the standard info structure S140. Characteristics are updated with formulae.
o
Check the formulae of the characteristics.
The availability check and the transfer of requirements do not need to be active.
Overview of the control elements for the product allocation check In SD Customizing you must take t he following control elements into account: 1. The product allocation determination procuedure determines how product allocation is carried out. It must be entered in the material master record in the basic data screen. 2. The product allocation object is used by the availability check to check against product allocations. During the product allocation check, the system checks the product allocations stored in the planning hierarchy that are created for each product allocation object. 3. In the product allocation hierarchy, an info structure is assigned to the product allocation determination procedure. This info structure influences the criteria which determine how the product allocations are stored in the planning hierarchy. 4. In the "Control product allocation" node, one or more product allocation objects are assigned to the product allocation determination procedure. Every object has its own validity period. During the availability check, the relevant object is determined using the delivery date from the order. The object and the info structure from the product allocation hierarchy are used to determine the planning hierarchy in which the product allocations (being checked against) are stored. 5. Similar to the availability check against ATP quantities, you must specify whether a product allocation check is to be carried out at requirements class level and schedule line level or not. SD Customizing also controls the following control options that help you during product allocation: 1. When assigning info structrues to product allocation determination procedures (in the product allocation hierarchy) you can display the appropriate statistical info structures. 2. You can check whether the settings are consistent for every combination of product allocation determination procedure and product allocation object (determined in "control product allocation"). 3. Collective product allocations can be entered automatically into a planning hierarchy. In Customizing for LIS, you must take the following control element into account: The info structure determines the criteria for the planning hierarchy (e.g. the organizational data). N ote
If the unit of measure of the order quantity does not correspond to the planning unit of measure, the order quantity is converted automatically before product allocation is checked.
1.MAITAIN
PROCEDURE
Maintain Procedure In this IMG activity you define the product allocation determination procedure for the availability check against product allocations. It determines how products are allocated and is used as follows: o
The product allocation determination procedure must be entered in the material master (basic data screen, general data).
o
In the product allocation hierarchy, an info structure is assigned to the product allocation determination procudure. The info structure determines the criteria for the planning hierarchy. The product allocation is stored in the planning hierarchy.
o
Several objects with different validity periods can be assigned to the product allocation determination procedure.
Activities To create a new product allocation determination procedure, proceed as follows: 1. Enter an alphanumerical key with a maximum of 18 places for the procedure as well as a suitable description. 2. Make sure that the product allocation determination procedure is entered in the material master record.
DEFINE OBJECT
Define Object In this IMG activity you define the product allocation object. This product allocation object is the object in the product allocation determination procedure. This is because product allocations are stored in the planning hierarchy by object. You can assign the product allocation object to a product allocation determination procedure under the 'Control product allocation' node. This assignment is a precondition for the product allocation determination procedure to be carried out on the object Activities 1. Specify the product allocation object using a key of not more than 18 places and a description. 2. Make sure that the product allocation object is assigned to a product allocation determination procedure.
SPECIFY HEIRARCHY
Specify Hierarchy In this IMG activity, you assign an info structure to each of the product allocation determination procedures. You can display the suitable statistical structures. The system uses both the assignment of the info structure to the product allocation determination procedure and the product allocation object to determine the planning hierarchy in which the product allocations are stored, relevant for the check. You can specify a formatting character for each info structure and this is used to form the key for general entries (default entries). Once the planning hierarchy has been created, you can expand the planning hierarchy with general entries using the node 'Permit collective product allocation in info structures'. This creates a default entry for every node in the hierarchy. Indicator for product allocation method Set this indicator to define which of the two available methods you want to use for offsetting the order quantity against the product allocation quantity. They are as follows: y
If you do not set the indicator, the system will use the 3.0F product allocation method (discrete ATP check). Using this method, the system offsets the quantity confirmed in the sales document against the product allocation quantity. It uses only the product allocation quantities from current and future periods (unused product allocation quantities from past periods are not taken into account). The update date in the relevant activation rule of the product allocation information structure is used to to determine the periods. The system only allows three dates: delivery date, material availability date, and planned goods issue date.
Example: Product allocation quantities: January February March 50 50 50 50
April 50
May
If a customer places an order on 03/01 for 150 PCS, ATP proposes 50 PCS for March, 50 PCS for April, and 50 PCS for May. The remaining unused quantities from January and February are not taken into account. When you use this method, note that you cannot use the following product allocation functions: o
o
y
Consumption periods: Here you can define a number of past and future periods that should be used as the valid consumption period. Allocation steps: Here you can define several product allocation steps with different info structures. The only valid hierarchy step value is 0.
If you set the indicator, the system uses the standard product allocation method available as of 4.0A. This method involves a checking logic that corresponds with the ATP cumulation logic. In this method, the system uses the standard ATP checking logic to offset the quantity against the unused product allocation quantities. The system includes unused product allocation quantities from previous periods when calculating the available product allocation quantity for the current period. Example: Product allocation quantities: January February March 50 50 50 50
April 50
May
If a customer places an order on 03/01 for 150 PCS, ATP first cumulates the unused product allocation quantities from past periods (50 PCS for January and 50 PCS for February) to calculate the available product allocation quantity as 150 PCS. As a result of this check, 150 PCS are confirmed for the relevant date. Note: Furthermore, you can use the following additional product allocation functions: o
Consumption periods: Here you can define a number of past and future periods to be used as the valid consumption period. This is then integrated into the cumulation logic in order to identify how many prior or future periods should be taken into account for unused product allocation quantities.
o
Allocation steps: Here you can define several product allocation steps with different checking logic. You can use this function to perform the following checks, for example: Step 1: Check order quantity against plant capacity for the relevant periods Step 2: Check order quantity against the customer's permitted product allocation quantities
N ote
You can use a single info structure for several product allocation determination procedures. However, all procedures assigned to an info structure must have the same product allocation indicator. This means that an info structure supports either discrete or cumulative ATP. Furthermore, you can use a structure only once in one procedure. Note
You must use the same formatting character for each info structure, even if the info structure is assigned to different determination procedures. If an info structure has been assigned several times, assignment is permitted with or without a formatting character. However, deviating formatting characters for the same info structure are not allowed. Activities 1. Assign info structures to the product allocation determination procedures. 2. Specify for which combination you want to use the formatting character.
DEFINE CONSUMPTION PEROIDS
Define Consumption Periods When you have defined a product allocation determination procedure, you can also define (past and future) consumption periods for product allocation quantities. These periods consist of the number of past and future periods. These two parts work together as follows:
y
y
The number of past periods identifies the number of periods before the product allocation date in the order, which can be used for calculating the current consumption period. The unused product allocation quantities of these past periods are then cumulated before the product allocation for the current period is checked. The number of future periods identifies the number of periods after the product allocation date in the order, which can be used for the current consumption period. If the requested quantity is not confirmed within the future period, any remaining quantities will remain unconfirmed.
Note: In both cases, the periods are defined by the activation rule from the corresponding information structure (period = daily, weekly, monthly, etc.). However, the actual date used to represent the order date depends on the update rule. The consumption periods are only valid if you have set the indicator for the NEW product allocation method. If you have chosen to use the old product allocation method, this functionality is not available. You can use the consumption periods in the following ways: # of past periods
# of future periods
999
999 0
Result Unlimited product allocation999
Unlimited cumulation of unused quantities of past periods and no future product allocation quantities
999
No cumulation of unused product allocation quantities of past periods, unlimited future product allocation quantities This represents the old product allocation method of 3.0F.
CONTROL PRODUCT ALLOCATION AREA
0
Control Product Allocation In this IMG activity, you assign one or several objects with different validity periods to the product allocation determination procedures. The validity periods cannot overlap. The relevant product allocation object is determined using the delivery date from the order. The planning hierarchy with the stored product allocations is determined using the product allocation object. No product allocation check is carried out for validity periods that are not active (in these cases, a product allocation object must be assigned for technical database reasons) Activities 1. Assign the product allocation objects to the product allocation determination procedures. 2. Specify a validity period for every object. 3. Select active or non-active status for each assignment.
DEFINE FLOW ACCORDING TO REQUIREMENT CATEGORY
Define Flow According To Requirement Category In this IMG activity you determine whether the system should run an availability check for product allocations or not. You can determine this in each requirements class. Activities Select the product allocation field for the requirements classes for which the system should run an availability check against product allocations.
PROCESS FLOW FOR EACH SCHEDULE LINE CATEGORY
Process Flow For Each Schedule Line Category In this IMG activity, you determine for each shedule line category, whether or not an availability check against product allocation is to be carried out. The availablity check against product allocation can only be deactivated at schedule line category level. It cannot be activated if the availability check is not already activated at requirements class level Activities Deactivate the availability check against product allocation for those schedule line categories for which you do not require the check to be carried out. If you want to activate the check, you first have to make sure that the check is active at requirements class level.
PERMIT COLLECTIVE PRODUCT ALLCOATION INFO STUCTURE
Permit Collective Product Allocation In Info Structures
After the planning hierarchy has been created, you can use this IMG activity to create general entries in the planning hierarchy. This creates a default entry for every node in the hierarchy. This is carried out independently of the product allocation object. The masking symbol is determined from the hierarchy. At the same time, you can enter and distribute the product allocations in the hierarchy. During subsequent expansion of a hierarchy, the report for these new entries can create further general entries without changing the entries that already exist. Precondition The planning hierarchy must already be maintained. Activities Enter the info structure of the planning hierarchy in which you want to enter collective product allocation.
Check Settings In Product Allocation For every combination of product allocation determination procedure and product allocation object (determined in 'control product allocation') you can check whether the settings made are consistent. You can also determine how the check results are to be issued. Activities 1. Enter the combinations of product allocation determination procedure and product allocation object for which you want to check the settings.
2. Also specify how you want the results to be issued.
3. RULE BASED AVAILABILTY CHECK
Rule-based Availability Check This enables you to use a rules-based availability check. For example, you can carry out an availability check in several plants and with several alternative materials. This availability check takes place in the stand-alone APO planning system (Advanced Planner and Optimizer) from SAP. The source system triggers the availability check in the APO system which then returns the result of the check to the source system. The result of the APO availability check contains a list of materials, plants and quantities. Each partial result of the availability check is stored as a lower-level item for the original item in the document to be checked.
Requirements You can only use the rules-based availability check for materials that have been correspondingly indicated and that have been copied to the APO planning system. This takes place with the integration model in the source system (transaction CIF).
DEFINE BUSINESS TRANSACTION
Define business transaction In this step you can define the business transactions. These transactions must also be available in the APO planning system. Here the availability check control is carried out for the transactions. You can find the business transactions in the APO planning system (Field BPROC) under: Global ATP -> Settings -> Rule-based ATP -> Conditions -> Assign rule strategy .
ASSIGING BUSINESS Transaction To sales Order TYPE
Assign business transaction to sales order type In this IMG activity, you assign the actions you defined previously to the order types. This activates the availability check settings for this order type, that were maintained in the APO planning system.
COPying Characteristics values For sub items
Copying of Characteristic Values for Sub-Items Use In this IMG activity, you can control how the system processes configured subitems that were generated by the rulebased availability check.
TRANSFER OF REQUIREMENTS
Transfer of Requirements By means of the transfer of requirements, the MRP department is informed about the quantities and deadlines by which incoming orders should be delivered. The system checks the availability of the goods based on the requested delivery date of the customer and creates MRP records which contain all necessary information for passing on to materials planning. The transfer of requirements ensures that the goods are available in time for the delivery. Materials planning transfers the reported requirements and creates production orders or purchase requisitions from them, for example. The following sections on the transfer of requirements describe how to control the transfer of requirements. The transfer of requirements is basically dependent upon the following factors: y
requirements type
y
requirement class
y
check group
y
schedule line category
Note
The transfer of requirements is controlled globally using the requirements class which is derived from the requirements type for all sales document types. For the sales document types, fine tuning is also possible at schedule line level. This fine tuning is described in the section "Defining the procedure for each schedule line category" . Note that the requirements classes are also used in production so you should coordinate any changes to the requirements classes with production. The requirements type and, eventually, requirements class are determined in the strategy group so all changes made there should also be coordinated with production. Requirements transferred to planning are further processed in the module MM. You must, therefore, coordinate the transfer of requirements with the module MM. Requirements For controlling transfer of requirements, you have to carry out the following steps: 1. Each requirement type has to be allocated to one requirement class only. 2. The transfer of requirements must be switched on at requirements class level, the sales documents at schedule line level. 3. You must define a check group. It is possible to have this check group proposed for the initial creation of a material master record. 4. Note that a plant must exist for transfer of requirements to be carried out at document item level. Note
Requirements transferred to planning are further processed in the module MM. You must, therefore, coordinate the transfer of requirements with the module MM.
DEFINE REQUIREMENT CLASSES
Define Requirements Classes In this menu option, you define and maintain the requirement classes with which you control all functions relevant to requirements in logistics. The requirement class controls the MRP and the requirements consumption strategy as well as the relevancy for planning. Specifications on the settlement of the requirement class, for example, the settlement profile and the results analysis key, are preferably used by Materials Management and do not have to be used when configuring the availability check and transfer of requirements. The requirement class specifies the following points: y
y
y
whether an availability check and a transfer of requirements is carried out for a transaction (for sales documents, fine tuning using the schedule line category is possible, see note), whether the requirements are relevant for MRP, the allocation indicator from the sales view which controls the settlement of customer requirements with planned independent requirements
y
whether an item is to be settled to an auxiliary account assignment,
y
the settlement profile,
y
the results analysis key.
Note
The availability check and transfer of requirements are controlled globally using the requirement class for all sales document types. For the sales document types, fine tuning is also possible at schedule line level. The specifications from the requirement class are transferred to the schedule lines as a default value and can be overwritten. Fine tuning of the sales document types using the schedule line category is described in the section "Defining the procedure for each schedule line category" . For information on independent requirements allocation and independent requirements reduction, see the manual "SD Sales". The configurations for independent requirements allocation are described in the Implementation Guide for Production Planning in the chapter "Demand Management". Actions 1. Check first whether the requirement classes available in the standard version are sufficient for your demands. 2. If necessary, enter a new key for the requirement class, which can have up to three characters, and a description. 3. Specify whether an availability check and/or a transfer of requirements should be carried out for the requirement class. At requirements class level, the availability check can only be activated at the same time as the transfer of requirements. On the other hand, the transfer of requirements can be activated independently of the availability check. 4. Specify whether a requirement is relevant for MRP. 5. Specify for the allocation indicator whether a settlement of customer requirements with planned independent requirements should be carried out by allocating a consumption strategy to the requirement class. The allocation indicator corresponds to the settlement indicator which is maintained in planned independent requirements management. Customer requirements can only be settled with planned independent requirements types to which the same consumption strategy was allocated in independent requirements planning. 6. Specify the indicator for requirements reduction, if necessary. N otes
You can make the settings for the requirements class which concern costing and account assignment in the following activity: Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Maintain requirements classes for costing/account assignment .
DEFINE REQUIREMENT TYPE
Define Requirements Types In this IMG step, you change or define requirements types which identify the different requirements, such as sales order requirements, delivery requirements or individual customer requirements. The requirements types can be changed, for example, in order to represent customer-specific terms. Together with the item category and the MRP type of the material, an allocation to the individual transactions in sales and distribution is carried out by means of the requirements type. requirements type. Every requirements type is allocated to a requirements class with its corresponding control features. While a requirements type is allocated to a single requirements class, a requirements class can be allocated to several requirements types. As a result, it is possible to control different transactions in a uniform manner with regard to their technical procedure. Note
The requirements type is displayed in the sales document and can be changed there. Actions 1. Check first whether the requirements types available in the standard version are sufficient for your demands. 2. If necessary, enter an alphanumeric key for a requirements type, which can have up to four characters, and a description. 3. Allocate a requirements class to the requirements type.
DETERMINATION OF REQUIREMENT TYPES USING TRANSACTION
Determination Of Requirement Types Using Transaction In the standard system, requirements types are determined according to a specific search strategy beginning with the material strategy group. Strategy for Determining the Requirements Type 1. First, an attempt is made to find a requirements type using the strategy group in the material master. 2. If the strategy group has not been maintained, the system will determine it using the MRP group. 3. If the MRP group has not been defined, the system uses the material type instead of the MRP group when accessing the corresponding control tables. 4. If no requirements type is found here, the system assumes a special rule and attempts to find a requirements type with the aid of the item category and the MRP type. 5. If this is not possible, a last attempt is made to find a requirements type with the item category only. 6. If the last attempt fails, the system declares the transaction as not relevant for the availability check or transfer of requirements. Note
You can select an alternative search strategy in the 'Source' field, for example a transaction-related procedure for determining requirements type (source = 1 or 2).
Example There are business transactions, such as consignment stock processing, in which the material with its planning characteristics is not important, rather the transaction itself. An issue from the customer's consignment stock should not trigger an availability check against planning at the plant as layed down by the planning strategy but rather against special stock. Actions 1. Assign the item categories and MRP type to the requirements types. 2. Select an alternative search strategy in the 'Source' field if necessary. Notes
for determining requirements types in releases previous to 3.0
Up to and including Release 2.0, requirements types were determined using the document item category and MRP type of the material in the relevant plant. As of release 2.1, this specification is carried out identically for Logistics by means of the MRP group of the material which specifies a strategy from which the requirements type is determined.
DEFINE PROCEDURE FOR EACH SCHEDULE LINE CATEGORY
BLOCK QUANTITY CONFIRMATION IN DELIVERY BLOCKS
DELIVERIES BLOCKING REASONS CRITERIA
REASONS FOR SCOPE OF DELIVERIES BLOCKS ANS TRANSFER OF REQUIREMENT
Block Quantity Confirmation In Delivery Blocks When requirements are transferred to MRP, the confirmed quantity is also reserved for confirmed sales documents. If a transaction is blocked for delivery, the required stock will be blocked so it cannot be used elsewhere. To prevent this, you can block the transfer of requirements for a delivery block in this step. In this case, the ordered quantity will still be transferred to MRP as a requirement but the quantity will not be reserved. This is apparent in the document when no confirmed quantities are available after saving (see schedule line screen). When the block is removed, the system automatically carries out an availability check. Additionally, you may push back the material staging date by a number of days. Note
You can carry out availability checks at any time, in spite of the blocks, if the transaction permits. The system then creates temporary schedule lines with confirmed quantities which are then removed when the document is saved. You can find further information on defining blocking reasons in the section "Define blocking reasons in shipping" . Requirements The delivery blocks must already be defined (see the section "Define blocking reasons in sales"). Actions 1. Check when it is necessary in your company to block the transfer of requirements for blocked order items.
MAINTAIN REQUIREMENTS FOR TRANSFER OF REQUIREMENT
Maintain Requirements For Transfer Of Requirements In this step you can maintain your own requirements for the transfer of requirements. The order quantity is always copied as a requirement in planning. With requirements, you can prevent quantity reservations and with them confirmed quantities. You can recognize this after saving a document: confirmed quantities will no longer exist (see initial screen). Standard settings In the standard SAP System, requirement 102 prevents reservations from being created in the event of a credit block.
MAINTAIN REQUIREMENTS FOR PURCHASE AND ASSEMBLY ORDERS
Maintain Requirements For Purchase And Assembly Orders In this step you can maintain your own requirements for creating purchase requisitions. Standard settings In the standard SAP System, requirement 101 prevents purchase requisitions from being created in the event of a credit block.
Checking Group for Availability Check This field has two uses: 1. Specifies whether and how the system checks availability and generates requirements for materials planning. 2. In Flexible Planning, defines - together with the checking rule - the different MRP elements that make up this key figure. The sum of these elements gives the key figure.
Use 1: Availability Checking and Materials Planning U se
The value you enter for use 1 (see above) is a default value which defines:
y
y
y
Which MRP elements (for example, purchase orders, reservations) the system includes in the availability check Whether the system checks availability only until the end of the replenishment lead time or whether it checks availability over the entire period for which MRP elements exist Whether the system generates individual requirements or summarized requirements if you enter sales orders or deliveries for the material
Use 2: Flexible Planning Dependencies If you use this field to define the MRP elements of a key figure for Flexible Planning, you must also select Document KF in the Customizing parameters of the information structure
