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. 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:

 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.

 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:

 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:

 Planned delivery (MRP 1)

  GR processing time (MRP 1)

 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.

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" 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.

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:

 Requirements class

 Requirements type

 Checking group

 Checking rule

 Schedule line category

 Strategy group

 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

Sales and Distribution (SD)

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:

 Inquiry

 Quotation

 Sales order

 Outline agreement (contracts and scheduling agreements)

 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

 Requirements on weekdays

 Requirements on Easter Monday

 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:

 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.

 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 100 0 0 -
SALES ORD 2 -100 0 0 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:

  carry out the planning run

 reschedule

 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:

 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.

 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:

 cumulate the confirmed quantities when creating and changing

 cumulate the requirements quantity when creating, no cumulation when only making changes

 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 WITH ATP LOGIC OR AGAINST PLANNING

Define checking group

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:

 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.

 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 100 0 0 -

SALES ORD 2 -100 0 0 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:

 carry out the planning run

 reschedule

 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:

 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.

 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:

 cumulate the confirmed quantities when creating and changing

 cumulate the requirements quantity when creating, no cumulation when only making changes

 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 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.

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:

 purchase orders

 production orders

 purchase requisitions

 planned orders

 dependent requirements

 reservations

 dependent reservations

 sales requirements

 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:

 Safety stock (to be maintained in material master record, MRP data)

 Stock in transfer in the receiving plant

 Stock in quality inspection

 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:
  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.

 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.

 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:

 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 the 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).

Note

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:

 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    April       May

50        50         50       50         50

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 Consumption periods: Here you can define a number of past and future periods that should be
used as the valid consumption period.

o 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    April       May

50        50         50       50         50

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
Note

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:
  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         # of future    Result
periods           periods
999                 999           Unlimited product allocation 999       
0           Unlimited cumulation of unused
                                  quantities of past periods and no
                                  future product allocation quantities   0     
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

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 rule-
based 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:

 requirements type

 requirement class

 check group

 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:

 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

 whether an item is to be settled to an auxiliary account assignment,

 the settlement profile,

 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.

Notes

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

Use

The value you enter for use 1 (see above) is a default value which defines:

 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