Vous êtes sur la page 1sur 49

Allocation Run

PDF download from SAP Help Portal:


http://help.sap.com/saphelp_afs50/helpdata/en/56/028e39b7b3972ce10000000a114084/content.htm
Created on October 13, 2016

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2016 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 49

Table of content
1 Allocation Run
1.1 Steps in the Allocation Run
1.1.1 Selection
1.1.1.1 Access Rule
1.1.1.2 Dynamic Open to Delivery Date Adjustment
1.1.1.3 Flagging Orders for Special Handling
1.1.2 Requirements Check
1.1.3 Requirements Grouping
1.1.3.1 General Requirements Grouping
1.1.3.2 Customer-Specific Requirements Grouping
1.1.4 Customer Service Areas (CSA)
1.1.4.1 Creating the Customer Service Area Table
1.1.4.1.1 Example: CSA Table
1.1.4.2 Assigning Allocation Groups to Customer Service Areas
1.1.4.3 Maintaining Responsibilities for Customer Service Areas
1.1.4.4 Managing CSR Stock
1.1.4.5 Finding Additional Stock
1.1.4.5.1 Example: Finding Additional Stock
1.1.4.6 Automatic Batch Determination
1.1.4.7 Automatic Storage Location Determination
1.1.5 Stock and Requirements Sorting
1.1.6 Allocation
1.1.6.1 Allocation Rule
1.1.6.2 Material Substitution
1.1.6.2.1 Customizing for Material Substitution
1.1.6.3 Allocation of Value-Added Services (VAS)
1.1.6.4 Allocation Status and MRP Status
1.1.6.5 Allocation Against SD Contracts
1.1.6.6 Allocation Against Future Receipts
1.1.6.6.1 Consequences of Changing Sales Orders
1.1.6.6.2 Consequences of Changing Purchase Orders
1.1.6.6.3 Consequences of Changing Production Orders
1.1.6.6.4 Consequences of Changing Confirmations
1.1.6.6.5 Consequences of Changing Goods Receipts Dates
1.1.7 Release Check
1.1.7.1 Release Check for Schedule Line Groups and Delivery Groups
1.1.7.2 Cancellation and Season Release
1.2 Execution of an Allocation Run
1.3 Parallel ARun Execution
1.4 Preview
1.5 Fill-Up or Reallocation
1.5.1 Action Rule
1.5.2 Reallocation Rule
1.6 ARun Optimizer
1.6.1 Rejecting Open Quantities
1.6.2 Redistributing Allocated Quantities Within an Allocation Group
1.6.3 Executing Total Reallocation in the ARun Optimizer
1.6.4 Accessing Sales Orders from the ARun Optimizer
1.6.5 Authorization for Tasks Within the ARun Optimizer
1.6.6 Creating Custom Reports in the ARun Optimizer
1.7 Background Processing
1.7.1 Selection Sets
1.7.1.1 Deletion of Obsolete Selection Sets
1.7.2 Reorganization
1.8 Special Order Types
1.9 Availability Check and Allocation Run
1.10 Check Tools for ARun
1.10.1 ARun Customizing Check Report
1.10.2 ARun Delivery Check Report

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 49

!--a11y-->

1 Allocation Run
Purpose
The special situation of the apparel and footwear industry requires an optimization of the assignment of existing stock to open requirements. If a stock
shortage occurs, the allocation run ensures an optimal assignment of stock to the open requirements. The allocation run distributes the currently available
stock to due sales orders according to certain calculation logics at a specific time. If the ordered quantities are larger than the actually available stock, you
can use the allocation run to reach the best customer satisfaction under the given circumstances in your business. You can use the ARun Optimizer, you can
check and manually correct the results of the allocation run if necessary.

Prerequisites
You have to carry out an allocation run before delivery of any AFS materials. The allocation run is mandatory and cannot be switched off. The allocation type
always determines the allocation run. The allocation type forms a framework and contains all allocation rules and checks that have been defined for a certain
business process.

Process Flow
The allocation process begins with the sales order creation and the accompanying availability check. In the apparel and footwear industry there are several
weeks or months between the order creation and the delivery of the goods to the customer. In this time period, the quantity of the ordered materials can be
reduced due to several reasons. You must then decide how this insufficient quantity should be distributed among the existing orders.
1. In the first step of the allocation run (Selection) you must determine which requirements should participate in the next allocation run as well as which
stock the allocation run should access. The physically existing stock as well as certain future receipts like, purchase orders, confirmations and production
orders are considered during allocation. In preview mode purchase requisitions and planned orders are considered as well. In this case, you can set the
allocation run so that it accesses future goods receipts that refer to existing purchase requisitions. It checks if the goods receipts might be able to cover
the requirements of the selected orders at a specific time/ time period in the future.
2. In the second step (Requirements Check), the selected orders can be checked to see if they have:
delivery block
their cancellation date is exceeded
they have a credit block
they have a valid season assigned
the maximum number of partial deliveries for that item is reached during the Allocation Run
These orders can then be excluded by the subsequent steps of the allocation run.
3. In the third step (Requirements Grouping), you can group sales orders by certain criteria, which enables you to further process each allocation group. The
grouping is the prerequisite for using the allocation logic equal distribution .
4. In the fourth step (Stock/ Requirements Sorting), you can define a sort rule and depending on your settings you can override the original sequence of
the incoming orders for the allocation process. The sorting is the tool for the optimal distribution of the insufficient quantity of stock among the existing
orders according to specific criteria. For example, customers with high priority due to their sales volume or their importance in the market, are given
preference and are supplied with the goods first.

If no sort rule is maintained or if the sort rule does not contain a sorting parameter, the sort sequence will be random.
5. In the fifth step (Allocation), the actual allocation of the available stock to the selected orders takes place according to the chosen allocation logic . The
allocation is carried out based on the sorting criteria. Allocation is possible using FIFO logic (first in first out) and the equal distribution logic. Requirements
Grouping is a prerequisite when using the Equal Distribution logic, and when using the FIFO logic with the only up to release quantity option. In case there
is a maximum quota defined in the release rule, the allocation would happen only up to that quantity. See also Material Substitution.
6. In the sixth step of the allocation run (Release), the system checks whether the minimum quantities that are defined in the release rules could be
fulfilled. If this is not the case, the allocated quantity can either be reserved for a certain order or the stock will be used for the next selected order.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 49

Execution
The allocation run can be carried out in four different modes. Besides the normal mode that actually assigns the stock, there is a simulation mode that does
not update stock. The preview mode can allocate future goods receipts just like the simulation mode. Both of the preview modes (2,4) can be used as an early
warning system since they take future material availability into account. You can save the results of the preview modes and whenever necessary, process and
evaluate them.
You can carry out the allocation with all functions both online and in the background. The selection set is available for the background processing of the
allocation run and Reorganization is available for the ARun Optimizer.

Result
In the next step, you can create a delivery for the materials that have passed the release checks and then post the goods issue.

!--a11y-->

1.1 Steps in the Allocation Run


The allocation run is subdivided into the following steps.
Selection
Requirements Check
Requirements Grouping
Stock and Requirements Sorting
Allocation
Release
Allocation and MRP Status

!--a11y-->

1.1.1 Selection
Use
You must transfer the information to the allocation type regarding which requirements should be selected and which stock can be used for the coverage of
these requirements. For this you define the rule for the requirements selection and the stock selection in Customizing. Then you must enter both rules in the
allocation type.
In addition, you must define which date field of the sales order the system should access during the requirements selection and how it should carry out this
access to the database. For this you can use the material or partner index or directly access the database. The access definition is carried out via the access
rule, which you must also enter in the allocation type.

Integration
When you start the allocation run, you must enter an open-to-delivery date in the selection screen of the allocation run. This time window depends on the date
field you have defined in the allocation type.

You have selected the order date field confirmed delivery date (EDATU) in the allocation type. If you now start the allocation run with your
allocation type, you must choose a period of time when the material should be open to delivery. Select the sales orders whose confirmed
delivery date is within this period.

Features
Rule for the Requirements Selection
So that the allocation type knows which requirements should be allocated, you must create the rule for the requirements selection. You can only select sales
orders in the selection.
Rule for the Stock Selection

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 49

In the allocation type, the Rule for the Stock Selection field controls which stock the allocation run should access to satisfy the above mentioned
requirements.
You can allocate the companys own and the external stock. However, with the companys own stock you must differentiate between the actual stock and the
future receipts. The normal mode of the allocation run can only allocate physical stock, purchase orders, confirmations, and production orders. This means
you can only select purchase requisitions and planned orders if you carry out the allocation run in the preview mode.

If you start the allocation run in the normal mode and if it accesses purchase requisitions and planned orders, it is not possible to assign the
selected requirements to the stock.

!--a11y-->

1.1.1.1 Access Rule


Use
With the aid of the access rule you specify how the system should access certain data. You can use index tables (material and partner index) or have the
system directly read the tables (direct access). If the access is via an index, the runtime is improved during the allocation.

When using a specific index, you should maintain the corresponding index key field in the ARun selection.

Partner index: Partner from/to, Partner Function (AG)


If you do not maintain the appropriate index field in the selection, it could lead to long runtimes, since the complete master data table (material
master, customer master) must be read.

Features
In the application of the allocation run and in the IMG you can define your own display variant with certain fields and preassigned entries, which you can enter
in the access rule as a default value. Every time you start your allocation type, this variant is called and you can use your predefined field catalog.

!--a11y-->

Dynamic Open to Delivery Date Adjustment


Use
The system automatically calculates the open-to-delivery (OTD) window for an allocation run. All open schedule lines having delivery dates falling in this
window and matching the selection criteria are automatically included in the allocation run. You can specify exactly how the system is to determine this date.

Activities
You can either enter the beginning and ending dates manually in the Open to delivery date range fields, or have the system calculate them automatically. To
calculate automatically, you can make one or more of the following entries:
Base date. The default is the system date, but you can override this with a past or future date of your choice.
Adjusted delivery from date (this is a number of days, not a date)
Adjusted delivery to date (this is a number of days, not a date)
Only valid working days included when calculating the starting and ending dates.
You can use the open to delivery date range either:
Directly on the selection screen when executing an ARun. This is a one-time event.
In the selection set. In this case, the system will calculate the date range whenever you execute an ARun using this selection set.

The open-to-delivery window is recalculated each time the allocation run uses the selection set.
Example
As normal practice, you want allocation runs for a given selection set to include all orders due for delivery within a seven day period starting three days in the
past and ending four days in the future. For this case, the entries would be as follows:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 49

Field

Value

Open to delivery

(Blank -- system will calculate this)

Base date

(Blank -- system will use current date)

Adjusted delivery from date

-3

Adjusted delivery to date

If today is November 10, then the allocation run includes all sales orders from November 7 to November 14, assuming shipping takes place seven days a
week. If November 7 is a holiday in your logistics calendar and no shipments will be made, then the From date is pushed ahead one day to November 8.
Likewise, if a one of the days in the future is a holiday, the To date is moved ahead to November 15. Whenever a beginning or an ending date falls on a
nonshipment date, the system moves ahead to the next valid shipping date.
If you enter the OTD range, you only need to enter either the beginning or ending date; the system calculates forward or backward to determine the other end
of the delivery window. Hence, the following entries would give the same result:
Field

Value

Open to delivery

(Blank -- system will calculate this)

Base date

11/14/2001

Adjusted delivery from date

-7

Adjusted delivery to date

(Blank -- system will calculate this)

This tells the system to calculate 7 days back from 11/14/2001 to determine the beginning date.

A minus sign tells the system to subtract the number of days from the base date. An entry without a sign indicates that the system should add
that number of days to the base date. It is also possible to have minus signs in both of the adjusted delivery date fields. This only makes
sense if the entry in the From date is larger than To date.

!--a11y-->

Flagging Orders for Special Handling


Use
You can flag schedule lines for special handling; for example, high priority customers, promotions, limited internal distribution, early allocation, hold orders, or
other situations you wish to define. You create flags in Customizing for each of these situations, along with priority information and special release fillrates for
schedule lines.
In the ARun release phase, the system checks schedule lines first for any special handling instructions as defined by the Customizing flags. Depending on the
configuration, the schedule lines could have a priority field for ARun sorting purposes, or the quantity to be allocated could be restricted to a certain maximum.
If there are no special fillrates for a schedule line, the system uses the standard ones.
Flagging goes all the way down to the schedule line level, so all schedule lines for a flagged line (for example, on each level and path) automatically inherit the
flag.
You can limit an ARun based on these flags; for example, perform allocations only for high priority customers. To do this, go to the ARun Selection Screen
and choose the Flagging field on the Sales 2 tab page.

Prerequisites
To set up special handling flags:
1. In the IMG, choose AFS Allocation Run ARun Optimizer ARun Optimizer Control Special Handling (Flag Orders).
The ARun: Allocation Priority Screen appears.
2. Choose New Entries .
3. Enter a new 2-character flag and a description (for example, HP for High Priority Customer).
4. Enter the parameters you want to assign to the flag rule.
5. Choose Save .

Indicating a priority here does not imply that orders with this flag will be allocated before other orders.

Example
You have new ski boots that you want to market in your retail outlets. You want to provide each store with one pair of boots as a sample. You have 20
stores and 40 pairs of sample boots. If each store requested two pairs of these boots, the orders would be filled. However, you want to hold some back in
inventory in case some of the boots become damaged or lost in the stores.
To do this, create a limitation rule with 1 in Maximum Quota and drop in Open Quantity . The system allocates a total of 20 pairs of boots (one for each
store), drops the remaining requirements and keeps the remainder in inventory.
Your customer requires a minimum fulfillment of 75% of an order, with a minimum of 60% in the heart sizes. However, you have a new jogging outfit that is
expected to be a hot item. For this material, the customer will be satisfied with a fulfillment of 50% of the order provided out of which at least 80% are in
the heart sizes.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 49

To do this, create a limitation rule with 50 in Min. Quota (Size) and 80 in Min. Quota (Heart Size) . This special release check rule overrides the normal
75% and 60% quotas for this specific material. Other materials that the customer has ordered will still be subject to the normal 75% and 60% quotas.

!--a11y-->

Requirements Check
Use
With the aid of the checking rule for the exclusion of sales orders, you can exclude orders from the allocation, which you have already selected for an
allocation run. This way you can prevent, for example, orders of credit blocked customers from getting the stock that should be used for solvent customers.
There are different criteria and checks available for this.

Features
After you have decided which requirements the allocation run should access (for example, sales orders should be allocated), you can check these
requirements for the following criteria:

Does the selected order have a credit block at header level?


Does the selected order have a delivery block at header level or item level?
Is the cancellation date of the entire order or of an individual item exceeded or are these dates reached in a certain number of days?
Are there items in the selected order whose materials do not belong to a valid season?
Has the maximum number of permitted partial deliveries been reached?

If these criteria should be checked, you must define the system reaction. A negative result of these checks can either lead to a termination of the allocation
run or to an information or warning message. Both messages are only available if the allocation run is carried out online. If the system reaction is defined as
an error, the orders or items that have passed one of the above mentioned checks participates in the further steps of the allocation run. That means they
cannot be allocated in this allocation run.
Combine the above-mentioned checks in a checking rule in Customizing. The result of failed checks can be saved in a log file. The failure of a checking rule is
displayed in the form of traffic lights in the allocation list in the online application of the allocation run.

!--a11y-->

1.1.3 Requirements Grouping


Use
You can group different individual requirements in individual allocation groups. The formation of allocation groups is the prerequisite for using allocation logic
other than the FIFO logic. You can additionally assign release rules to the individual groups and you can sort by allocation groups within the requirements
sorting. You can form groups using general criteria or form them customer-specifically.
Using the requirements grouping you can filter individual requirements out of the population and combine them so that you can handle them separately in the
allocation run.

Features
General Requirements Grouping
You can use a grouping rule to determine which standards the system must use to form the individual allocation groups. This means, that each requirement
will be assigned to one allocation group. You can form any number of requirements groups. You can assign individual release rules and allocation logics to
individual groups or you can carry out the assignment for all groups according to the rules of the allocation type.
You can define a grouping rule in Customizing of the allocation run and maintain the rule in the corresponding allocation type.
Customer-Specific Requirements Grouping
You can select individual grouping rules for the requirements of certain customers. This is an enhancement of the general requirements grouping. You cannot
exclusively use the customer-specific grouping.
In addition to the general requirements grouping, you must define a grouping strategy and enter it in the customer master of the respective customer. By using
a determination rule, you control which grouping rules are assigned to the grouping strategy.
The function of the requirements grouping is optional. When configuring the allocation run you should make sure it is really necessary to form allocation groups
because this might affect the runtime.
Permanent Grouping

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 49

In addition, permanent grouping is also possible. At the time of creation of a sales order, allocation group numbers are assigned to a sales order
based on certain criterion. These group numbers are used to group certain requirements during an allocation run. Allocation groups are used in the
Optimizer field application 2, to perform operations on stock within an allocation group.
!--a11y-->

1.1.3.1 General Requirements Grouping


Use
Using a grouping rule you combine all requirements that are selected for an allocation run into individual groups. The grouping is controlled via the grouping rule
of the allocation type used. Here the requirements of all customers are grouped according to the same criteria. Here the requirements of all customers are
grouped according to the same criteria.
You need the general requirements grouping to carry out an allocation according to the equal distribution rule.
It can also be used for the special handling of individual requirements:
You can use individual release rules and allocation logics that deviate from the rules that are set in the allocation type.
It is also possible to use allocation groups as sort criteria within the requirements sorting.

Integration
You must maintain and activate the grouping rule in the corresponding allocation types.
If you want to use the allocation function in full, the general requirements grouping must be activated. The system assigns the existing stock to the
requirements of the individual allocation groups. This procedure is controlled via the allocation logics. For allocation runs without requirements grouping, the
allocation is always carried out via the FIFO (first-in-first-out) logic. If you form requirement groups, the allocation can be carried out via the equal distribution
logic.

Prerequisites
Activate the entered grouping rule in the allocation type by setting the grouping logic to S .

Features
Grouping Rule and Grouping Criteria
In the grouping rule you determine which criteria the system must use to group the customer requirements. The grouping criteria correspond to individual fields
of the sales order. The number of the groups is determined via the grouping criteria selection. This does not mean, for example, that if you select two grouping
criteria, only two allocation groups will be formed. The number of groups depends on the number of characteristic values of the individual grouping criteria. For
example, if you choose the field Sold-To Party , you create an individual group for each sold-to party using the selected customer requirements. You can also
determine the allocation groups by using a combination of several grouping criteria. This causes the number of the created groups to increase accordingly. You
can only use the group fields that you get via the match code help as grouping criteria. The system assigns the internal group numbers in a random sequence.
External Group Numbers
If you want to use individual release checks and allocation logics for individual groups, you must flag the corresponding groups with an external group number.
The external group numbers are a prerequisite for using allocation groups as sort criteria in the requirements sorting. The external group numbers are mapped
as a six-digit, numeric key. However, you can also define your own keys by using a function module.
If the external group number should not be mapped via a six-digit, numeric key, you can rename the groups by using a function module.
Individual Group Release Rules
You can use different release rules for individual allocation groups. You do not need to set up a special allocation type to do this. You still control the allocation
run via the used allocation type. If you want to use this function you must assign an external group number to the requested allocation group.
Individual Group Allocation Logic
You can assign individual allocation logics to individual groups. To do this, the system needs an individual group release rule. However, this is not possible
with permanent grouping.
Requirements Sorting by Allocation Groups
You can use allocation groups to carry out requirements sorting. You thus control in which sequence the stock are assigned to the individual groups. The
external group numbers can be used as a sort criterion.

!--a11y-->

1.1.3.2 Customer-Specific Requirements Grouping


Use
In contrast to the general requirements grouping, here you can combine requirements of individual customers according to separate grouping rules. Although a
global grouping rule exists, the requirements grouping of different customers can be carried out according to different rules. You can process both the
requirements of an individual sold-to party as well as the requirements of several customers. Requirements that should not be grouped according to individual
rules are grouped using the global grouping rule.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 8 of 49

That means that for each allocation run you can use several grouping rules that access different requirements.

Integration
The customer-specific requirements grouping are controlled by the interaction of grouping rules, grouping strategies, and determination rules. Using the
determination rules you assign one or several grouping rules to a grouping strategy. You must enter the corresponding grouping strategies in the respective
customer master records.
Combine the requirements of customers without a grouping strategy according to the grouping rule of the allocation type. The customer-specific requirements
grouping do not affect these requirements.

Prerequisites
Activate the customer-specific requirements grouping in the allocation type by choosing sales order-dependent grouping logic .
The grouping rules you want to use must already be defined.

Features
1. Grouping Strategies
The grouping strategy determines the rules by which the special customer requirements are handled. You can assign several grouping rules to a strategy.
Thus you can allocate several requirements of a sold-to party differently. The allocation of grouping rules is carried out via determination rules.
2. Determination Rules
The determination rules are the connection between the grouping rules and the grouping strategies. Here you determine under which prerequisites which
grouping rule(s) are selected. With a key you determine which criteria are used for the selection. Here you must differentiate between a default key and an
extended key. Select the proposed criteria from the sales document type. You can use them to carry out the grouping rule determination. You can freely
define the fields of the extended key. That means you can access external tables that contain user-defined fields via a user exit. You define this user exit in
the IMG of the allocation run.
3. Grouping Rule and Grouping Criteria
See General Requirements Grouping
4. External Group Numbers
If you want to use individual release checks and allocation logics for individual groups, you must flag the corresponding groups with an external group number.
The external group numbers are a prerequisite for using allocation groups within the requirements sorting as sort criteria. The external group numbers are
mapped as a six-digit, numeric key. You can define your own keys by using a function module if a different mapping is required.
5. Individual Group Release Rules
See General Requirements Grouping
6. Individual Group Allocation Logic
See General Requirements Grouping
7. Requirements Sorting by Allocation Groups
The sorting is carried out on the basis of the external group numbers. In the standard system the external group numbers are displayed via a six-digit, numeric
key. You can begin the number assignment for every grouping rule anew with the number 1. That way you can assign identical group numbers for the groups of
different grouping rules. Since it is possible to use several grouping rules within an allocation run at the same time when using customer-specific requirements
grouping, there can be overlaps during the requirements sorting. To avoid this you can define a unique key as the sort criterion within the requirements sorting
instead of defining the field value for external group numbers as the sort criterion (for example, descriptions of the grouping rule + external group numbers).
This key is determined with the aid of the function module for alternative sorting.
8. Renaming of External Group Numbers
By uniquely naming the groups of all grouping rules you ensure that an unmistakable sort criterion is available.

!--a11y-->

1.1.4 Customer Service Areas (CSA)


Use
You can define Customer Service Areas (CSA) to uniquely identify a set of allocation groups (a set of orders grouped together based on your own criteria). The
CSA environment allows multiple users (in multiple locations) to own and manage the stock allocated to their sales orders, thus reducing or minimizing stock
contention.
The CSA belongs to a Customer Service Representative (CSR), who is the only person authorized and responsible for updating the orders and their allocation

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 9 of 49

statuses in the ARun Optimizer. In addition, you can make Customizing settings so that when a CSR deallocates stock for orders within the CSA, the freed
stock remains reserved for that CSR or the CSR's substitute (who inherits the authorizations of the CSR). This is referred to as CSR stock and is available to
the CSR for subsequent allocations.
With the proper authorization, it is possible to transfer CSR stock to unrestricted stock or to another CSR.

Prerequisites
You create CSAs via Customizing ( AFS Allocation Run

ARun Optimizer

Customer Service Areas ).

Integration
You can permanently group specific schedule lines together during order creation, based on predefined criteria of your choosing. These permanent groups are
called allocation groups. This feature is in addition to the temporary grouping function, where the groups are created dynamically during the Allocation Run.
You can assign multiple allocation groups to a Customer Service Area (CSA), but an allocation group can only be assigned to one CSA. Thus, there is an n :1
relationship between allocation groups and CSAs.
In the ARun Optimizer, CSRs are able to automatically retrieve orders for their assigned allocation groups so that the CSR owns both the orders and the stock
allocated to those orders. A CSR can work with his own stock and a user cannot use stock that belongs to some other CSR.

!--a11y-->

Creating the Customer Service Area Table


Purpose
You can use this Customizing transaction to create a table for determining Customer Service Areas (CSAs). You would probably only create one table, as it
will contain all the logic needed by the system to automatically generate customer service areas.

Process Flow
1. In Customizing for the AFS Allocation Run , choose ARun Optimizer Customer Service Areas CSA Table Generation .
2. The system displays a message indicating that the table is cross-client. Choose Continue to close the message window.
3. Enter a table name, along with a description. In Customizing for AFS Allocation Run , maintain the default table by choosing ARun Optimizer
Customer Service Areas
Application Default Table Maintenance.
4. For the Application field, the system will automatically propose an entry of 5 (generation of CSA fields).
5. On the Table Level Overview screen, double-click Field level in the dialog structure at the left side of the screen. The system displays a table with the
following column headers: Table Name, Field Name, Sequence , and Key . Here you enter the criteria for determining sales areas. Enter a new line for
each combination of source table name and field name.
Table Name
Enter one of the following table names. This tells the system where to locate the data element you specify in Field Name below.
Table

Contents

KUAGV

Sold-to partys view of the Customer Master Record

KUWEV

Ship-to partys view of the Customer Master Record

VBAK

Sales document: header data

VBAP

Sales document: item data

VBEP

Sales document: schedule line data

VBKD

Sales document: business data

VBPA

Sales document: partner

Field Name
Enter a field that is found in that table. For example, the sales order number would be found in table VBAK, while the material number would be in
table VBAP.
Sequence
Assign a number to each field you have listed for a given table, starting with number 1. The system uses this information to determine the sequence
in which it should access the fields. Here you do not need to enter the fields in order. The system resequences the fields internally based on the
numbers you entered here. However, you can improve system performance by assigning the lowest number to the most restrictive field (that is, the
data element having the most possible values).
Key
All fields should be marked as key fields and are used for determining the customer service areas. For example, if you are assigning customer
service representatives to geographical areas, you may want to designate the sold-to party location in table KUAGV as a key field.
6. Save your entries.
7. Return to the Table Level: Details view.
8. Choose Generate Table .

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 10 of 49

Result
The system generates a CSA table. As sales orders are processed, the system begins to fill in the table automatically as it encounters unique combinations of
key fields.
In a subsequent step, you assign customer service areas to allocation groups, and then customer service representatives to the customer service areas.

Example
See Example: CSA Table

!--a11y-->

1.1.4.1.1 Example: CSA Table


Suppose you specify the parameters for Customer Service Area (CSA) table as follows:

Table Name

Field Name

Sequence

VBAK

KUNNR (customer number)

Key

KUAGV

BLAND (location)

VBAP

WERKS (plant)

KUWEV

ORT01 (ship-to location)

Only those fields designated as key fields are stored in the CSA table.
Whenever sales orders are created, the system looks at the key fields Location and Plant to see if they form a unique combination. In this case, the key
fields are the customer location in the header data and the plant in the schedule line data.
Now suppose that you have five incoming orders (A, B, C, D, and E). The system processes the orders as follows:
1. Sales order A is for location NY and plant Buffalo. Since you just created the CSA table, it is empty and therefore this combination of NY and plant
Buffalo is unique. The system writes a line in the CSA table for this combination, and this becomes Customer Service Area 1.
2. Sales order B is for location CA and plant Los Angeles. The system compares this combination of key fields against the existing line in the CSA table.
Since this new combination is unique, the system again writes a line in the CSA table. This becomes Customer Service Area 2.
3. Sales order C is again for location NY and plant Buffalo. The system compares these key fields against entries in the CSA table: this combination already
exists in the CSA table, so it does not update the CSA table.
4. Sales order D is for location NY and plant Newark. (Although the sales order is from a New York customer, the closest plant is in New Jersey so that is
where the delivery originates.) Although the key field entry NY already exists in the table, the combination of NY and Newark does not. So the system
writes another line in the table. This becomes Customer Service Area 3.
5. Sales order E is for location AZ and plant Los Angeles. Although Los Angeles already exists in the table, location AZ does not. The system writes another
line in the table for Customer Service Area 4.
After the system processes these five sales orders, the previously empty CSA table now contains four lines corresponding to four sales areas. (Key fields are
shaded in gray.)

Plant

Location

Customer Number

Ship-To Location

CSA Number

Buffalo

NY

10000

Syracuse

0000000001

Los Angeles

CA

10023

San Diego

0000000002

Newark

NY

11894

Brooklyn

0000000003

Los Angeles

AZ

12445

Phoenix

0000000004

!--a11y-->

Assigning Allocation Groups to Customer Service Areas


Use
Customer service representatives (CSRs) need to manage all sales orders for their region. For this reason, the system must determine the customer service
area (CSA) for each sales order. The CSA is one of the criteria for determining allocation groups.
One CSA can contain several allocation groups. However, an allocation group can only be assigned to exactly one CSA.
Similarly, one CSR can be responsible for multiple CSAs. However, each CSA can only be assigned to exactly one CSR. This prevents a CSR from

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 11 of 49

Similarly, one CSR can be responsible for multiple CSAs. However, each CSA can only be assigned to exactly one CSR. This prevents a CSR from
mistakenly affecting sales orders in another CSRs region.

Integration
The way in which the system determines CSA's is similar to how it determines allocation groups. (See Requirements Grouping for more information on
allocation groups.) CSA determination is triggered you create or change sales orders, and is integrated into the allocation group determination process.
The system first checks the criteria for building an allocation group. The CSA could be one of these criteria, such as when the origin CSA is a key field in the
allocation group table. Another nonkey CSA field is generated automatically if the allocation group table is linked to a CSA.
When you save (update) a sales order, the system assigns each schedule line to an allocation group table. Each allocation group table is assigned to a CSA
as well.

The system does not automatically assign a CSR. If you want the system to assign a CSR to a new CSA, you use the CSA Handling Report
(/AFS/ARUN_CSA_HANDLING). This report will give you greater flexibility in changing CSAs or changing the relationship between allocation
groups and CSAs.

Prerequisites
The allocation group table contains one line for each allocation group. You need to create only one allocation group table; however, it is possible to create
multiple tables if you wish. You create the allocation group table in Customizing for AFS Allocation Run ARun Optimizer Permanent Grouping
Allocation Group Table Generation .

!--a11y-->

Maintaining Responsibilities for Customer Service Areas


Use
Use this transaction to add, delete, or change assignments of customer service representatives (CSRs) to customer service areas (CSAs).

Process
1. On the Customer Service Area Handling screen, enter the selection criteria for the CSAs you want to maintain.
For example, you can enter a range of sales areas you want to reassign (perhaps for an entire geographical region) or see all changes made by a given
user. If you also select the Number of AGs field, the resulting list indicates the number of allocation groups for each CSA (this is for information only and
does not affect the database).
2. Choose Execute .
The system displays a list of all CSAs matching your selection criteria.
3. Do one of the following:
You can assign one or more CSAs to a CSR.
You can reassign all CSAs for a given representative (for example, if a new person is taking over all CSAs for someone who has moved to a different
position). In this case, you enter the user name of the previous representative along with the name of the new representative.
You can assign or reassign substitutes for a CSR. Substitutes have the same authorizations as their corresponding CSRs.
You can merge two or more CSAs into one area by selecting the CSAs and choosing Merge CSA Responsibilities.

Suppose you merge CSA 123 (whose CSR is Smith) and CSA 456 (whose CSR is Garcia) and call the new region 456. All the allocation
groups belonging to the previous areas are now assigned to 456 and the CSR is Garcia. The screen still shows CSA 123 for Smith, but the
traffic light for that line turns is red, indicating that no allocation groups are assigned to that CSA. If you exit the transaction and then reenter,
the old CSA longer appears in the list.
You can divide a CSA into smaller ones by selecting the CSA and choosing Split CSA Responsibilities .
The system displays a list of all allocation groups assigned to the CSA. Select a line and choose Assign CSA to AGs . When the dialog box
appears, choose the CSA that is now to be responsible for the allocation group. For the next line, you can choose the same or a different CSA, and
so on. You can reassign one allocation group to exactly one CSA.
You can flag a CSA for deletion by selecting it and choosing Delete . The traffic turns from green to yellow or red. For example, if an allocation group
is still assigned to the CSA, the yellow warning light appears. If you choose to proceed with the deletion flag, the system displays a warning message
and asks you to check the exception log first before proceeding.

This does not just flag the representative for deletion; it marks the entire CSA for deletion, so use caution when using this function. The CSA
is not physically deleted with this transaction. To carry out the actual deletion, run the /AFS/ARUN_CSA_REORGANISATION report.
If you have one or more traffic lights that are yellow or red, you can select the lines and choose Show Exceptions Log . The log indicates the problem
(for example, if you have just created a new CSA but have not assigned any allocation groups to it).
4. When you are finished, make sure to select all the lines you have modified. Then choose Save . The changed lines have to be selected or else, the
system displays a message informing you the same.

Result
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 12 of 49

The system updates the list, along with the date and the user name of the person who made the change, plus an icon showing the type of change made. The
traffic lights and icons from the latest changes no longer appear.

!--a11y-->

1.1.4.4 Managing CSR Stock


Purpose
Customer service representatives (CSRs) will probably use the Stock Management Report (/AFS/CSR_STOCK_INIT) on a daily basis to:
Take free available stock from inventory and put it into CSR stock for their own use (referred to as CSR stock)
Return unused stock to free available inventory
Reassign some of their stock to another CSR (customer service representative) if needed

Process Flow
1. Access the Stock Management Report (/AFS/CSR_STOCK_INIT).
2. On the selection screen, choose the stock source and stock destination. For example, if you want to take stock from inventory, choose Free available
stock as the source and CSR stock of user as the destination.

If you select Free available stock as the source and CSR stock of user as the destination but do not enter a user name, the system will
assume you want the stock to be moved to your own area; otherwise you can enter a user name to transfer the stock to someone else. If Free
available stock is the source, then you must enter at least one combination of material and plant in the table.
If you select CSR stock of user as the source and Free available stock as the destination and also leave the entire table blank, this will
clear out all of your stock and put it back into inventory. Likewise if you indicate another CSR as the destination, this transfers your entire
stock to the other CSR.
You must enter the material and plant for the stock you want to transfer.
If you leave the Grid value field blank, all grid values of that material in that plant will be selected.
If you leave the Quantity field blank, the entire free available stock of that material in that plant will be selected

If you enter a quantity of 50 but no grid value, the system will select 50 of each grid value (for example, 50 small, 50 large, and so on).
Likewise, if you enter grid value XL but no quantity, the system will select the entire stock of material in grid value XL in that plant. So normally
you would enter both a grid value and a quantity.
3. Choose Execute . The system displays a list of materials matching your criteria, along with quantities for each grid value.
If a quantity shown is less than you specified, it is because there was insufficient stock in inventory. You cannot change the stock quantities in the list
4. Select one or more lines, and then choose Move stock .
5. When the system asks you to confirm the stock posting, choose Yes . Any lines you did not select will not be transferred.

Result
After posting, the system returns to the selection screen and displays a Stock posted message.
You can move more stock if you wish by entering more selection criteria.

!--a11y-->

1.1.4.5 Finding Additional Stock


Use
Normally, customer service representatives (CSRs) take quantities from unrestricted stock and place them into CSR stock. This stock is then reserved, or
owned, by the individual CSRs. From here, they can allocate this stock to their sales orders.
If you dont have enough stock of a material in CSR stock, you can find out who else might have additional stock available by choosing Goto Stock in the
ARun Optimizer. The system displays a dialog box showing the quantity of available stock:

In your own CSR stock


Reserved by other CSRs
Free available stock (unrestricted stock that has not been reserved by anyone).
Currently assigned to your orders
Currently assigned by other CSRs to their orders

You can then decide how best to obtain additional stock.

This information is for display only, to help you decide how best to proceed. You cannot move stock using this function. Once you decide what
you want to do, you exit the display and select a different transaction (for example, placing more stock into the CSR stock).

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 13 of 49

Integration
If you deallocate stock from an order, it goes into your private stock a temporary buffer. This stock is immediately available to you, and you alone have
access to it; no other CSRs can see or take this stock until you save the transaction. Once you save, the stock in your private buffer is moved to CSR stock.
Only then will other CSRs with the appropriate permissions be able to access to this stock.

Example
See Example: Finding Additional Stock

Prerequisites
In Customizing for the ARun Optimizer, the node Configure ARun Optimizer Type contains several fields in the Find Stock section of the screen. The first
five fields allow you to define the sequence (priority) in which the system attempts to find stock

Own (CSR, private)


Other CSR stock
Free available stock
Own assignments
Other CSR assignments

Assign a unique number (1 to 5) to each field. For example, if you enter 1 in the Own (CSR, private) field, then the system first tries to find stock in this area
first before trying anywhere else (such as free available stock). If you leave a field blank, the system ignores that stock in its search for suitable material.
There is also a Stop Logic field. This field determines whether the system stops searching as soon as it finds sufficient material in one of the stock
categories above

Suppose you have a requirement for 100 pieces but only 60 pieces have been allocated. The system will attempt to locate another 40 pieces
by searching the other stock categories in the sequence you defined above. The entry in the Stop logic field has the following effect:
1 = Complete the search for all stock categories, even if the system finds 40 or more pieces available in the first stock category searched. The system looks
for 40 pieces in each stock category; this lets the user know whether he or she could take the full requirement of stock from any one of several different areas.
2 = Stop the search as soon as 40 pieces are found within any given stock category.
The second option gives quicker results, since the system does not have to check every category every time.

!--a11y-->

1.1.4.5.1 Example: Finding Additional Stock


You are accessing your requirements in the ARun Optimizer. One of your orders is for 100 white Tshirts in size XL. Only 40 are allocated to the order, which
is not enough to satisfy the release requirements. You select the material and choose Goto Stock . The system displays the various types of stock that
can be viewed.
The resulting dialog box depends on the menu option you chose. The first one is Own Stock (CSR and private) and it shows the quantity currently in CSR
stock. This stock is freely available to fill orders and is not reserved for other assignments.
You see there are 30 Tshirts in CSR stock. You allocate these 30 to your order, which brings the total up to 70 Tshirts. You next check the Own
Assignments , where you see that you have already allocated 90 Tshirts to your other orders. At this point, you can decide whether this order has a higher
priority than your other orders, in which case you can exit the dialog box and reallocate stock from your other orders to this one.
Alternatively, you can check Free Available Stock to see if there is stock in inventory. You find 10 more Tshirts. You can then exit the dialog box and use
the stock management transaction to move these 10 from unrestricted stock and place it into CSR stock. This brings you up to 80. You still need an additional
20.
You next select Other CSR Stock . Here you find that CSR Mary has assigned 213 Tshirts to her orders, and CSR Eduardo has assigned 87 to his orders.
You talk to Mary and see whether she is willing to let you have some of her stock. She agrees. She deallocates 20 Tshirts and moves them back into CSR
stock (or into unrestricted stock, depending on Customizing settings). You can now take this 20 and allocate them to your order. This now brings you up to a
total of 100 Tshirts, thus fulfilling the order.

!--a11y-->

1.1.4.6 Automatic Batch Determination


Purpose
Use this process if you want to make sure that a particular customer requirement (sales order/material/SKU) will be covered with stock from a specific batch.
For example, you may want to set aside remainders of extra large men's T-shirts to be sold to specific markets at end of season.

Prerequisites
In Customizing for allocation rules, you must select the Consider Batch Number flag and then assign this allocation rule to the desired ARun type. If batch

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 14 of 49

number determination is not active in your ARun allocation rule, ARun allocates the first free available batch and does not consider any special batches.
At time of goods receipt, you must create a unique batch number for the merchandise.

Example
Suppose that you receive a shipment of 1000 men's T-shirts. Of these, 50 are men's size XL. You assign batch number MEN_ALL_XL to the XL shirts. Orders
from Customer A are to be filled only with stock from this batch.
When ARun is executed, it encounters sales orders for Customers A and B, each requiring 50 men's XL T-shirts. It assigns the following:
50 T-shirts from batch MEN_ALL_XL to Customer A
50 T-shirts from general stock to Customer B
This assumes that ARun processes orders from Customer A first. If, however, ARun encounters Customer B orders before Customer A, it can assign the 50
T-shirts from the batch to Customer B. In this case, Customer B's order will be filled, but Customer A must wait until additional T-shirts are added to batch
MEN_ALL_XL and ARun is executed again. In other words, Customer A can receive goods only from batch MEN_ALL_XL, but there is nothing preventing
ARun from also using that stock to fill other customer orders as well.

!--a11y-->

Automatic Storage Location Determination


Purpose
Use this process if you want to make sure that a particular customer demand (sales order/material/SKU) will be covered with stock from a specific storage
location. For example, you may have first quality running shoes in storage location 0001 and factory seconds or samples in storage location 0002. You want to
specify the appropriate storage location in the sales order to make sure the customer receives the correct merchandise.

Prerequisites
In Customizing for allocation rules, you must select the Storage Loc. flag and then assign this allocation rule to the desired ARun type. When you execute
ARun with this allocation rule, the program checks the sales order for a storage location. If a storage location is entered, ARun fills the order with merchandise
only from that location.
If storage location determination is not active in your ARun allocation rule, ARun allocates merchandise from any location.

!--a11y-->

1.1.5 Stock and Requirements Sorting


Use
Using the sort rule you can sort requirements at order and schedule line level, and thus override the original sequence in which the orders were placed. The
orders are put in a different sequence to meet your requirements. The new sequence is now the basis for the allocation. You can also sort stock in this
manner.

You want orders of A customers to always be handled with a higher priority than the orders of B and C customers. That means that the
important customers are served first in critical situations.
A stock sorting is for example useful if you want to make sure that the materials that are placed in storage first are the first to be consumed, that is, allocated.

Integration
The formation of the sort rule extensively influences other functions of the allocation run:
1. When using the sort sequence remember that the sorting is carried out first by fields at header level, then at item level and finally at schedule line level.
If this is ignored, splitting of the total order can occur, which in certain release rule combinations might lead to the requirements being split and thus to
undesired partial deliveries: If you sort at a level that is below the level at which your release rule carries out the release check, the order or item can be
split (for example, if sorting is carried out according to the confirmed delivery date, but the release rule checks the minimum quantities at item level).
If your business process does not allow any other option for sorting, you can repair and recombine these splittings in the allocation. To do this, use the
function Final Release Check .

Item

Schedule Line

Pieces

Color

Confirmed Delivery Date

10

50

Green

5.12.1999

20

10

Red

5.11.1999

20

20

Yellow

6.12.1999

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 15 of 49

In this case the result of the sorting is as follows:

Item

Schedule Line

Pieces

Color

Confirmed Delivery Date

20

10

Red

5.11.1999

10

50

Green

5.12.1999

20

20

Yellow

6.12.1999

As item 20 was split into two parts, the system carries out the release check for both parts separately. If 10 pieces of color red are available in the
example, but 20 pieces of color yellow are not, then the system would release the 10 red pieces, but not the 20 yellow pieces. To avoid this, you must
always activate the final release check that is set in the allocation type.
2. If you want to sort by schedule line fields in all orders, you must use the function module Prepare 1 in the Allocation Logic during the preparation. This
can negatively affect the runtimes during the allocation run.

Prerequisites
Every allocation type must have a sort rule.
The field catalog, which contains the sort criteria, can be enhanced in the IMG node Define Rules for Stock/Requirements Sorting . Remember that the
enhancement of the sort fields is a modification.

Features
The sort rule contains a field catalog with sort fields. You choose the fields from the field catalog that are important for your business processes and put them
in a sequence. In the next step you can compare the selected fields with constants. For example, you can define that customer X always has the highest
priority. In the following step you can use your own sort logic with the help of a function module.
You can also sort by allocation groups.

!--a11y-->

1.1.6 Allocation
Use
With the aid of the allocation settings you can determine which principle the system should use to distribute existing material quantities among the individual
requirements. If there is not enough stock, the allocation can either be according to the FIFO principle or the principle of equal distribution. When allocating
with FIFO (first-in-first-out), the existing stock is assigned to the requirements according to the existing sorting. That means requirements that have a high
priority due to the requirements sorting will be fully allocated, while requirements with a lower prioritization get little or no stock and therefore cannot be
released. When allocating with equal distribution, existing stock can be equally distributed among the individual requirements of an allocation group according
to certain rules.

Prerequisites
To carry out an allocation using the principle of equal distribution, you must form allocation groups by using requirements grouping. You can store the
respective allocation logic in the related release rule for the different allocation groups.

Features
Allocation Logic
With allocation logic you can determine which principle should be used for the allocation. The allocation logic consists of the following components:
ARun Function Module for the Allocation Preparation
The ARun function module for preparing the allocation determines the field contents for the internal requirements sorting. Here you can use one of two
function modules:
J_3AR_ALLOCATION_PREPARE_1: Use this function module if you want to sort at schedule line level first.
J_3AR_ALLOCATION_PREPARE_2: Use this function module if you want to sort at header and item level first.
Allocation logic
By selecting the relevant radio button, you control whether the allocation takes place according to the FIFO principle or the equal distribution principle.
You can also use the option Only upto Rlease Quantity . This option only applies if a requirement cannot be fulfilled completely. If there is not enough stock
available, the system will allocate up to the release quantity (release percentage on the schedule line level).
The following example describes the allocation results that the different settings of the allocation logic can lead to:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 16 of 49

In Case 1, the allocation is carried out according to the FIFO logic. The requirements of the first allocation group are completely fulfilled. The remaining
quantity of 25 is only sufficient to fulfill the first requirement of group 2 up to the minimum quota.
In Case 2, the allocation is carried out using an equal distribution combined with a material shortage logic up to the minimum release quantity. After the
requirements of the first allocation group are also completely covered, the remaining quantity is equally distributed among the requirements of the second
group.
In Case 3, a FIFO distribution with a material shortage logic up to the confirmed quantity is set in the allocation logic. Since a maximum quantity of 70% is
entered in the release rule, the allocation from the sales order is carried out up to this value instead up to the confirmed quantity.
In Case 4 there is also a material shortage logic up to the confirmed quantity used. Since an equal distribution is used here, the system equally allocates the
remaining 55 pieces to the requirements of group 2 (with the remaining quantity logic from the start of the current allocation group, therefore an allocation of 28
pieces to requirement 3).

Allocation
Here you can determine whether stock and requirements categories are taken into account during the allocation run. Using the allocation, the system is told
whether and in which form the category check should be executed. The category check can be carried out in the following levels:
1. No category check is carried out. You make this selection if you do not use stock and requirements categories in your business processes.
2. The system only checks whether valid combinations of stock and requirement segments exist for the respective coverage strategies (controlled via the
material master). This option might be useful when using the preview mode because at this point in time it is not necessary to carry out a completely
detailed category check. We recommend using this option for runtime reasons.
3. The allocation run executes a complete and thorough category check in all the requirements you have selected. Based on the category sequence in your
Customizing, each schedule line of each item in an order is checked to see whether a matching stock segment with physical warehouse stock exists for
this requirements segment, so that it can be ultimately allocated. This variant of the category check might cause a somewhat longer runtime. The runtime
can be increased based on different criteria, such as the number of possibly existing categories plus the number of requirements to be selected. The more
categories must be checked for your materials and the higher the number of requirements found, the longer the runtime will be.
See also Allocation Against Future Receipts.

Note
You can use different release rules for different requirements within an allocation run (see Release Rules, Requirements Grouping). For these requirements you
can use an allocation logic that deviates from the logic you maintained in the allocation type. Enter the requested allocation logics in the corresponding release
rules.

!--a11y-->

1.1.6.1 Allocation Rule


Use
The allocation rule controls how the system assigns stock to requirements during the allocation run.

Prerequisites
You have defined the Customizing settings by choosing AFS Allocation Run ARun Detail Define Allocation Logic Allocation Rule
Requirements Date
In order to guarantee on-time delivery to your customers, the system determines the material availability date by checking the Material Master or the

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 17 of 49

configuration of the SD delivery scheduling rule. Factors that affect availability can include, for example, picking and packing time, loading time, and
goods receipt processing time.
You can specify that the availability date be based on one of the following:
Confirmed delivery date (EDATU) and shipping scheduling
The EDATU of the sales order is the confirmed date. Subtracting x days from EDATU give the material availability date (MBDAT).
Order Cancellation Date (J_3ACADA) and shipping sch eduling
This uses the same logic as above to find out how much time is needed to prepare a delivery to the customer before the cancel date. It is not
possible, however, to run a complete shipping scheduling. Instead, the system uses an approximation: it calculates the number of working days
between the confirmed delivery date and the material availability date (MBDAT). This number of days is subtracted from the cancel date to determine
a new requirement date. The new date may slightly differ from the date that shipping scheduling would have determined.

Cancel date = December 15


Confirmed date = November 1
Material available date = October 15
Nov 1 - Oct 15 = 12 working days
Dec 15 - 12 working days = November 27
Requested Delivery date and shipping scheduling
This uses the same calculation logic as above.
GR Date
This specifies which date is used for the stock availability check:
Schedule line date in the sales order
Receipt/requirements date
Physical Stock (Dynamic Stock Prioritization)
This determines the point in time when physical stock can be allocated. You enter a number of days here. Based on this, the system calculates a horizon
within which the confirmed date must lie in order to allow physical stock to be allocated. The horizon for batch stock is entered in the From field in
Customizing for dynamic stock validity in the allocation rule.
Future Stock (Dynamic Stock Prioritization)
You can define an allocation window for a stock element. If the requirement date is within the window (starting at the current day, then this stock can be
allocated. If you do not enter a safety window for a stock type (From = 0, To = 0), the system ignores that stock type.

You enter the following here:

Priority

Stock Type

From

To

Confirmations

25

Production Orders

10

Confirmations

30

30

For a sales order with a confirmed date of May 3, the allocation run could allocate purchase orders and confirmations only.
First preference will be given to a confirmation falling between the 20th of April and 30th of April.
In case, no confirmations with delivery dates in the above window are found, it would look for purchase orders between 25th of April and May 1st. If it still finds
no matching stock it would look for confirmations with delivery dates between April 15th and June 2nd.
If you want to consider the time needed to handle the goods receipt (for example, the time needed to unload the goods from the truck and place it into storage)
you adjust the allocation window by that number of days.
Field Checks
Batch Number
This specifies that the system only accept stock with the same batch number as entered in the sales order schedule line.
Storage Location
This specifies that the system only accept stock with the same storage location as entered in the sales order schedule line.
Category and Sort
This specifies that the system only accept stock with a category that matches the requirement category (coverage strategy).
If you activate this flag, only valid stock categories are allocated. If you also set the sort flag, the stock is consumed in the order in which the
categories are defined in category configuration (coverage strategy, allowed categories).

For example, assume you have categories A, B, and C. If the sort flag is not set, the categories might appear in the order B, C, A; but with the
flag set, they will appear in the order A, B, C.
Season End and Cancellation Date
These flags determine whether the system checks the cancellation and/or season end dates when allocating stock.
The system compares the current date against the schedule line dates in the purchase orders. For example, if the cancellation date in the sales order
is June 30, the system considers purchase orders with schedule lines prior June 30 as potential stock, but skips those that are past June 30.
The base date for all checks is the date you specified in Requirements Date above.
Stock Prioritization
This specifies whether the system is to use a stock sorting rule (which you must already have maintained in Customizing) or dynamic stock prioritization.

!--a11y-->

1.1.6.2 Material Substitution


PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 18 of 49

Use
It is occasionally necessary to allow substitution of one material for another within a sales order. This is due to inventory shortages resulting from higher than
usual consumer demand, delays in the supply chain, phasing out of an old style or color, or other considerations. The ability to identify and substitute
acceptable products in such situations helps to avoid lost sales and increases customer satisfaction with timely deliveries.
To define which materials may be substituted:
1. On the SAP Easy Access Screen , choose Logistics Sales and Distribution Master Data Products Material Determination .
2. Go to the Create Material Determination Initial Screen (VB11/VB12 in standard R/3 Enterprise) and select a material determination type.
3. In the MatEntered column, enter the material number for which you want to allow substitutions (original SKU). Then in the Material column, enter the
material number of the substitute (substitute SKU).
4. Save your entries.
During order pricing, the system recognizes whether a substitution has been made. It checks the substitution control rule in Customizing to see whether the
customer should given the price for the original material, the substitute material, or the lower of the two prices.
A contract call-off order can also trigger substitution. The substituted quantity is subtracted from the quantity of the originally ordered material item.
For multi-store orders, the ATP spread logic does the following:
FIFO: The system spreads the ATP quantities of the original material (if available, and if this is a partial substitution) starting with the first store. When
the original material is exhausted, the system then uses the substitute material. In this case, the first store has the highest percentage of original
material
Even spread: The system spreads the original and substitute materials evenly across all the stores.
You can use the material substitution either interactively or have it run automatically in the background:
Interactive: The system displays the substitute material as determined by the substitution rules in Customizing. Both the original and substitute material
are shown side by side on the screen, allowing you to compare them. You can choose whether or now you want to accept the proposed substitute.
Background processing: The system can automatically substitute materials based on the substitution rules in Customizing. There is no user
interaction. You can run mass document change with substitution turned on or off for all selected orders.
You can have temporarily locking of substitute materials during ATP processing. If you are in the ATP screen and are displaying substitute materials, all the
materials shown are locked for other users. As soon as you select a material, the lock is turned off and other users can then access those materials.

Prerequisites
See Customizing for Material Substitution.

Restrictions
Substitution is not supported for the following:

Stock transport orders (STO)


Special order types such as make-to-order (MTO), purchase-to-order (PTO), third-party order (TPO) and consignment
Contracts, inquiries and quotations
Substitution is not supported for materials with different base units of measure (UOM)

!--a11y-->

Customizing for Material Substitution


Purpose
To enable substitution, define the substitution logic in Customizing in the order listed below.

Process Flow
Creating substitution strategies (Optional)
1. In the IMG, choose one of the following:
AFS Allocation Run ARun Detail Substitution Substitution Strategy
Sales and Distribution Basic Functions Availability Check and Transfer of Requirements Availability Check AFS Substitution
Substitution Strategy
2. Enter a unique identification (4 alphanumeric) for this new strategy, plus a free-form description.
3. Save the strategy.

Creating rules

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 19 of 49

You can either use the existing substitution rules or create new ones. To create new rules:
1. In the IMG, choose one of the following:
AFS Allocation Run ARun Detail Substitution Substitution Rule
Sales and Distribution Basic Functions Availability Check and Transfer of Requirements Availability Check AFS Substitution
Substitution Rule
2. On the Substitution Rule Overview screen, choose New entries .
3. Enter a unique number for this new rule (up to 4 alphanumeric). Then fill in the rest of the fields.
Max.No.Subst
Enter the maximum number of substitutions permitted for each requirement within an allocation run.
Available Trigger
This parameter used for triggering substitution. It first calculates the coverage of the requirement quantity by regular stock. In case the percentage of
coverage is less than the specified available trigger percentage, substitution is triggered. For example, an entry of 70 here means that if there is
enough stock on hand to fill 70% of an order, then no substitutions should be made and the order will remain only 70% filled. If however, there is only
enough stock to fill 60%, then the remaining 40% should be filled with substitute material, thus filling 100% of the requirement.
Minimum Original %
Enter the minimum percentage of originally requested material that must available for a requirement before a partial substitution will be permitted.
For example, suppose you enter 20 here. Then if there is enough original material to fill 30% of the requirement (which is over the 20% minimum
trigger), then the remaining 70% will be filled with substitute material. However, if only 15% of original material is available (under the 20% minimum
trigger), then the entire requirement will be filled with substitute material; that is, the system will not allocate any original material to the requirement,
even though it is physically available.
Acceptance %
Enter the minimum percentage of one substitution that must be reached in order to allow substitution. If the available substitution percentage is below
the acceptance percentage, the substitution is dropped.
For example, suppose you enter 20 here. Then you have a requirement of 100 pieces and only 50 in stock. If the system finds only 10 pieces of the
substitute material in stock (less than the 20% needed for acceptance), the system does not perform the substitution and looks for another suitable
substitute material instead. If, on the other hand, you have 30 (more than the 20% needed for acceptance) of the substitute material, the system will
allocate it to the requirement.
Item
In this section, you activate substitution on the sales order item level for different types of substitution (for example, material substitution, plant
substitution and sequence of the plant substitution).
Schedule line
In this section, you activate substitution on the schedule line level for different types of substitution (for example, grid value, category, or sequence of
category substitution.
ATP
These parameters define how the system is to handle substitution during sales order ATP checks.
ARun
In this section, you determine whether a group of schedule lines should revert to the same material/plant if one of the schedule lines has substitute
information.
4. Save your entries.

Assigning substitution rules to strategies (Optional)


1. In the IMG, choose one of the following:
AFS Allocation Run ARun Detail Substitution Determination Table Maintenance
Sales and Distribution Basic Functions Availability Check and Transfer of Requirements Availability Check AFS Substitution
Determination Table Maintenance
2. Assign a substitution rule for each customer-specific substitution strategy you created. You can assign the same rule to different strategies.
3. Save your entries.

Assigning substitution strategies to customers (Optional)


1. In Customer Master Data , select the customer to whom you want to assign a substitution strategy.
2. Under sales area data, select AFS additional data and enter the substitution strategy you created above. Under ARun data, you can assign the
substitution strategy for ARun substitution.
3. Save your entries.

Activating the substitution logic


1. Do one of the following:
a. In the IMG, choose AFS Allocation Run ARun Optimizer ARun Optimizer Control ARun Type . Select the ARun type (allocation
type) you want to maintain
b. In the IMG, choose AFS Allocation Run ARun Detail ARun Type . Select the ARun type you want to maintain.
2. Choose Details.
3. Under the heading Substitution , maintain the following entries:
Substitution Rule
Enter an existing substitution rule. If you do not want to use the standard rules, you can create additional ones. (See Creating rules above.)
Determination logic
A = The system should always use the default substitution rule
C = The system should first check to see whether there is a customer-specific rule. If there is no substitution strategy in Customer master data, then
the system should use the default rule. If you have maintained a strategy in Customer master data but the system could not determine a substitution
rule, the system will not perform substitutions.
Material Determination
Any other user-defined substitution logic can also be used.
Determination MDP
This flag specifies which material determination procedure the system is to use:
-- Always use the default procedure.
-- Use the determination procedure in the order type. (This is the same procedure that is used in ATP substitution.) If no procedure is defined, the
system will use the default procedure.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 20 of 49

-- If you do not want the system to do any material substitution at all, leave this field blank.

This setting is relevant only for FIFO allocation logic. If you are using spread logic, the system will always use the default procedure.

!--a11y-->

Allocation of Value-Added Services (VAS)


Use
Customer service representatives (CSRs) need to manage customer sales orders at the allocation group, order/line group, material, and SKU levels. If a
material has a corresponding ATP-relevant value-added service (VAS) such as hangers, labeling and bagging services, ironing and so forth, the VAS quantity
should match the main material quantity; for example, one shirt should have exactly one brand label sewn into the collar. If a material is allocated 100% to a
certain order and the customer service representative decides to deallocate the material by 20%, then the VAS for that material should also be decreased by
the same percentage.
When you drill down to any allocation level, the system shows the applicable VAS for each material (if any).

Features
VAS Correlation can be performed during each one of these functions:
Deallocation
If you deallocate a material for a given order, the system attempts to deallocate the VAS by the same percentage. If a material is deallocated to 60% of
the confirmed quantity, the VAS will also be decreased to the 60% level. However, if the VAS was only allocated at 50%, then the system will take no
action on the VAS.
Reallocation
If you reallocate a material, the system attempts to reallocate the VAS by the same percentage. However, if the user attempts to reallocate a material by
100% but inventory shortfalls make only a 75% allocation possible, then the system allocates only enough VAS to match this 75% allocation
Blocking
When you block a material, the corresponding VAS is blocked as well.
Release
When you release a material, the corresponding VAS is released as well,

The system does not carry out any VAS release rule checks in the ARun Optimizer.
In ARun itself, though, the system does check the VAS release rule configured in Customizing for that customer. For example, if a material is
allocated at 90% but the corresponding VAS is allocated at only 50%, then the release rule determines whether the 90% is released (so that
not every material receives a VAS), or only 50% is released (so that the material and VAS quantities match exactly).
Adjustment
When a material quantity is adjusted up or down, the system attempts to allocate enough VAS to match the new quantity.
Selection
During allocation, whenever an allocation group, order, line group, line item, or schedule line is selected, any corresponding VAS materials are selected as
well (so long as the VAS schedule lines are in the same allocation group).

Prerequisites
In Customizing for the ARun Optimizer Type (IMG path: AFS Allocation Run ARun Optimizer ARun Optimizer Control Configure ARun Optimizer
Type ), you need to maintain the following settings for VAS:
Corr. time
This determines when the system is to check for VAS:
Blank = No checking
1 = Whenever an activity is relevant (for example, at deallocation). If you also select the Interaction flag below, then you will receive a message
every time you perform such an activity.
2 = Before saving. Instead of receiving messages after each activity, you receive only one when you save your work. This makes maintenance
quicker.
Interaction
This determines whether the VAS allocation will occur automatically or not:
Blank = Allocation handled in the background, and you will not be able to interact with the system during this process
1 = You will receive a message whenever you perform an activity that involves VAS handling.
Adjust VAS items
This determines how the system is to allocate VAS items when the main material quantity is changed:
Blank = No adjustment
X = Adjust the VAS quantity (allocate/deallocate). If the main material is either increased or decreased, the system will adjust the VAS quantity
upward or downward as necessary to match the main material quantity. (This is the recommended setting, as it provides the greatest degree of
automation.)
Adjust main items
This determines whether the system is to adjust the main material quantity if it encounters a shortage of VAS material:
Blank = No change to the quantities. The main material and VAS material quantities will not match.
X = Yes. If there is not enough VAS material, reduce the main material quantity,

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 21 of 49

When you select a line in the ARun Optimizer and choose Adjust , the system displays a dialog box that includes the current Customizing
settings for adjusting the VAS items and main items. You can temporarily override these settings interactively. This will not affect the
Customizing settings, and they will automatically display the original settings the next time you adjust a quantity.

!--a11y-->

1.1.6.4 Allocation Status and MRP Status


Use
The MRP status groups stock and requirements elements according to certain criteria. It is used, among other things, as a sort criterion during the display of
the stock/ requirements list. The allocation run results in assignments that are either released for delivery or reserved for delivery at a later date. Two special
statuses ( F and R ) are available so that the system can distinguish between released and reserved assignments.

Integration
The allocation status consists of the allocation event, the final action for the open quantities, and the final action for allocated quantities (determined by the
release check). The MRP status is determined from the combination of the three influencing factors. The allocation status is purely informational. It is
displayed, for example, in the application in the result screen of the allocation run and is used as a selection criterion in the ARun Optimizer and in
Reorganization.

Features
The allocation status determines the status of an allocation as a combination of the allocation event, the final action of open and allocated quantities, and the
resulting MRP status.
The following example describes how the MRP status of an assignment can be created:
1. If during an allocation run the event Release Passed coincides with the final action of the allocated quantity Delivery Creation , the result is an MRP
status that shows that this assignment is released for delivery ( F ).
2. If the release check fails because there is not enough stock to cover the minimum quota for the requirement, the allocated quantity gets status R
( reserved by ARun ) and not status F . The example described here only occurs if the release action parameter for the respective release check has been
defined as an error. That means the event R is not triggered if this parameter is defined as a warning or information.
3. If a credit check fails, the system also assigns status R for the allocated quantity, provided the final action R ( delivery creation ) is entered in the
release rule and the credit check action parameter has also been defined as an error ( E ).
4. Assignments to future receipts like purchase orders, confirmations and production orders can never get a Fixed (F) status and will always have a
Reserved (R) status. This is because these stock elements are not deliverable.
5. The Allocation Status for assignments to future receipts is always FUTR .

Components of the Allocation Status:


1. The allocation event describes the event that could result from the release rule (failed/passed), from the action rule, or from the manual block or release in
the ARun Optimizer. This provides the system with information as to why a requirement could not be allocated, for example.
2. The final action of the open or allocated quantities is copied from the release rule used. You control which reservation status the allocated quantities will be
in after the allocation run has been saved (for example, manual release required). Using the final action for open quantities you determine whether the
quantities that could not be allocated after the executed release checks should be deleted or whether they should remain open until enough stock can be
allocated.
3. Using the MRP status the system recognizes whether the materials that have been allocated by the allocation run are released for delivery or whether the
stock has only been reserved. Reserved stock is assigned to a requirement and cannot be used to cover other requirements. To create a delivery, there must

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 22 of 49

be a conversion to status Fixed Assignment (F) . You can carry out this conversion either with the aid of a fill-up of the ARun Optimizer or of Reorganization.
4. The allocation status itself does not directly affect subsequent system activities. Using the status you can merely determine the ARun-specific MRP
status. In addition, you can use the allocation status as a selection parameter in the ARun Optimizer. The allocation status also appears in the result display
of an allocation run. Since the status name is freely definable, a unique description can simplify the interpretation of individual allocation results (for example,
status CRED could mean that the quantity is only reserved because the credit check failed).

!--a11y-->

1.1.6.5 Allocation Against SD Contracts


Use
You can make fixed reservations for SD contracts using the allocation run (ARun) function. This allows you to physically reserve warehouse stock for your
customers in advance. Within the contract validity period, customers can now request partial quantities without running the risk that their contract purchase
orders might not be currently available.
You can process orders both with and without contracts in one allocation run.

Integration
ARun and MRP use different methods for determining the status of allocations. Use the following table to interpret the status and to make the appropriate
Customizing settings for your own situation:
Status

Description

Explanation

F
(ARun status)

Fixed

The stock has a fixed reservation and is assigned to the


requirements. Only stock with this status is eligible for
subsequent delivery note creation.

R
(ARun status)

Reserved

The stock is reserved and is assigned to the


requirements. No delivery notes can be created yet.
Stock must be physically in inventory in order to receive
status R.
Contract allocations can only have status R, not status
F.

Blocked

(MRP status)

MRP has blocked the requirements. If the physical


warehouse stock is not sufficient for the contract entry,
the quantity, which is not yet available, receives MRP
status B. The next time an inbound shipment of this
material is received, the system immediately assigns
sufficient stock to the contract requirements to cover the
status B quantity. The status of this new
stock/requirements assignment would then be T.

Unrestricted stock

The stock is immediately available.

Temporary

Stock assigned to requirements without guarantee, and

(MRP status)
T
(MRP status)

is subject to change.

You can use transaction J3AT (ARun) to assign unrestricted (status A) physical stock to SD contracts. You can have the system automatically create
allocations for contract requirements by assigning an ARun type to the appropriate contract document type. If you have entered an ARun type in Customizing
for sales order/contract handling (in ARun basic settings), then contract documents with that order type will automatically have status R when they are saved,
for the amount of unrestricted stock available.
Again, the system only assigns stock, which is physically contained in the warehouse, not future receipts.
If you have a sales order that references a contract (also called a contract release order ), and an ARun type has been maintained in ARun Customizing for
sales order/contract handling, the system can automatically assign status F to the assigned quantity, depending on the release rule. This allows follow-on
deliveries to be created for the sales order.
If a sales order references a contract, and the sales order quantity is less than the amount of stock with status R in the contract, the sales order can be filled
in one of two ways, depending on the setting in Customizing for sales order/contract handling (in ARun basic settings):
If the sales order quantity is covered by the quantity having status R in the contract and meets the sales order release rule, then that quantity will receive
status F in the sales order, and the sales order can be delivered. If it does not meet the release rule, then the available quantity will have status R and the
sales order will be processed again in the next ARun until the appropriate quantity is available.
The sales order takes the available quantity having status R in the contract, and the system assigns the remaining quantity from unrestricted stock to fill the
order requirements.

For example, suppose you have a contract for 100 pieces, only 50 of which have status R. If you have a sales order for 70 pieces, then either:
- The sales order will receive a quantity of 50 pieces (since that is all that is available in the contract) with status F or R, depending on the
release rule, or
- The sales order will receive a quantity of 50 pieces from the contract, plus 20 from unrestricted stock, so the entire 70 pieces is available for
delivery and will receive status F.
It is possible to reduce, reject, or delete quantities in a sales order with reference to a contract. If the Restore setting for the contract order type has been

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 23 of 49

activated in Customizing for sales order/contract handling (in ARun basic settings), then the quantity subtracted from the sales order is returned to the
contract. In addition, if you want to be able to return allocated quantities to the contract, you must activate the Automatic deallocation setting as well as the
Restore setting. Otherwise, the system will return an error message saying that deletion/reduction is not possible and the quantity remains reserved.
You can also specify in Customizing whether overconsumption is allowed or not. For example, if you have a contract for 100 pieces, overconsumption allows
you to create a sales order for 120 pieces with reference to the contract. However, if you subsequently reduce the sales order to 5, then 95 pieces are returned
to the contract (100 5), and the remaining 20 (the overconsumed amount) go into unrestricted stock.

Example
The following examples show how the system reacts to different contract scenarios:
Process

Condition

Result

Creating a contract

The contract type contains an ARun type

The quantity in the contract that is available in inventory


has status R (reserved).

The contract type does not contain an ARun type

The entire contract has status T (temporary)

Automatic deallocation is active

The schedule line has status T

Automatic deallocation is not active

Error message. Rejection is not possible.

Canceling the reason for rejecting a contract schedule


line

The order type contains an ARun type

"Reactivated" schedule lines return to status R

The order type does not contain an ARun type

The schedule line has status T

Reducing a schedule line quantity in an already


allocated contract

Automatic deallocation of the contract item category is


active

Warning message. The remaining quantity (after


reduction) has status R.

Automatic deallocation of the contract item category is


not active

Error message. Entire schedule line quantity retains


status R.

Automatic deallocation is active

Warning message. The quantity in the deleted


schedule line is deallocated. The remaining schedule
lines have status R.

Automatic deallocation is not active

Error message. Deallocation is not possible.

The contract type contains an ARun type

The added quantity that is available in inventory has

Rejecting a schedule line in an allocated contract

Deleting a schedule line from an allocated contract

Adding a quantity to an existing schedule line in an


already reserved contract

Adding a new schedule line, material, or item to an

status R (reserved).
The contract type does not contain an ARun type

The added quantity that is available in inventory has


status T

The contract type contains an ARun type

The added quantity that is available in inventory has

already reserved contract

Creating a sales order with reference to an already


allocated contract

Creating a sales order with reference to a nonallocated contract

Rejecting a schedule line with status R or F within a


sales order

status R (reserved).
The contract type does not contain an ARun type

The added quantity that is available in inventory has


status T

The sales order type contains an ARun type

The sales order has status F or R, depending on the


release rule

The sales order type does not contain an ARun type

Status R of the contract is transferred to the sales order

The sales order type contains an ARun type

The quantity may have status F, R, or T depending on


whether Customizing allows sales orders to be filled
from unstricted stock.

The sales order type does not contain an ARun type

The quantity has status T

Automatic deallocation is active in the item category for The quantity goes back to contract with status R.
the material ordered in the release
Automatic deallocation is not active in the item

Error message. Rejection is not possible.

category for the material ordered in the release


Canceling the reason for rejection in a sales order

The sales order type contains an ARun type

The reactivated schedule line may receive status F or


R, depending on the release rule.

Increasing the quantity of a schedule line within an

The sales order type contains an ARun type, and the

The schedule line receives status F.

allocated sales order

quantity increase is equal to or less than the open


quantity in the contract

Reducing the quantity of a schedule line in an


allocated sales order

The sales order type does not contain an ARun type

The schedule line receives status R.

Automatic deallocation is not active in the item


category for the material ordered in the sales order

Error message. Reduction is not possible.

Automatic deallocation is active in the item category for The reduced quantity is returned to the contract with
the material ordered in the sales order, and the
status R. The status of the sales order (R or F) remains
Restore setting is active
unchanged.
Automatic deallocation is active in the item category for The reduced quantity is returned to unrestricted stock.

Deleting a schedule line within an allocated sales


order

the material ordered in the sales order, but the


Restore setting is not active

The status of the sales order (R or F) remains


unchanged.

Automatic deallocation is not active in the item


category for the material ordered in the sales order

Error message. Deletion is not possible.

Automatic deallocation is active in the item category for The quantity of the deleted schedule line is returned to
the material ordered in the sales order, and the
the contract with status R.
Restore setting for the contract order type is active

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 24 of 49

Automatic deallocation is active in the item category for The deleted quantity is returned to unrestricted stock.
the material ordered in the sales order, and the
The status of the sales order (R or F) remains
Restore setting for the contract order type is not active unchanged.
Adding a new item or schedule line to an already
allocated sales order

The sales order type contains an ARun type, and the


added quantity is within the contract's open quantity

After saving the sales order, the new item or schedule


line receives status F or R, depending on Customizing
settings. The contract is updated.

The sales order type contains an ARun type, and the


added quantity is more than the contract's open
quantity

Depending on the Customizing settings for the order


category, overconsumption is either allowed or not. If it
is allowed, the added schedule line quantity has status
F or R. The contract is updated.

!--a11y-->

1.1.6.6 Allocation Against Future Receipts


Use
This AFS process allocates future receipts to sales orders. This enables you to reserve stock from a future receipt (for example, a couple of months in
advance) to be sure you will have the stock ready to fill the sales orders once the goods are received. This way, stock you have purchased on behalf of a
specific customer is reserved for exactly that customer, even before you receive the stock. You are thus able to make commitments to your customers based
on stock reservations.
The following types of future receipts are supported for mode 1 (normal) future allocation:
Purchase orders
Shipping notifications
Production orders

Integration
All functions and features in ARun treat future receipts as if it were unrestricted stock, with the following exception: future receipt allocations can only be given
the reserved status (MRP Status R). This status cannot be changed to fixed (MRP Status F).

In addition to the normal MRP status, there is a special future MRP status used for allocation against future receipts. This future MRP status
treats future receipts as if they were freely available physical stock. The future status indicates in advance what the MRP status would be
when all future goods receipts are posted.
See also the following:

Consequences
Consequences
Consequences
Consequences

of
of
of
of

Changing Sales Orders


Changing Purchase Orders
Changing Confirmations
Changing Goods Receipts Dates

Features
The system uses a best match strategy (dynamic stock prioritization) for pairing purchase orders and requirements. During the allocation process, the
system runs a date validity check. This ensures that incoming stock from purchase orders will fit within the time constraints for its assigned sales order.
For example, if Customer A has ordered 100 pieces of SKU 123 and you have created a purchase order for that SKU to cover the order, then the purchase
order should have a goods receipt date that is prior to the confirmed delivery date for the sales order. The system performs this check before allocation of
a single requirement. Future receipts that fail the check are ignored for the current requirement being checked; they may, however, be considered for other
requirements which fit the date constraints.
The release rule calculates the release to fixed status (MRP F) only on the basis of unrestricted stock.

For example, suppose you have an order for 100 pieces with an 80% release rule.
If an assignment achieves 80% fulfillment from a purchase order (future receipt) and 20% from unrestricted stock, all assignments will be
given reserved status (MRP R).
Conversely, if you have 80% fulfillment from unrestricted stock and 20% from a purchase order, the assignment using physical stock will be
set to fixed status (MRP F) because the release percentage is over 80%. However, the second assignment using the purchase order will retain
MRP status R.
A second release check calculates the release on the basis of all assigned stock.

Using the above example, you have an order for 100 pieces with an 80% release rule. If an assignment achieves 80% fulfillment from a
purchase order (future receipt) and 20% from unrestricted stock, all assignments will be given future fixed (MRP F).
Business Add-Ins (BAdIs) are available for the following:
Deallocation when changing purchase orders and shipping notifications
Deallocation when changing sales orders
Deallocation during goods receipt
Sorting for deallocations
Deallocation during ARun Optimizer and ARun reorganization
Preallocation of best matching stock

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 25 of 49

Restrictions
Secondary requirements are not supported for ARun mode 1 (normal). This includes components of production and subcontracting orders.
Purchase requisitions and planned orders are not supported for mode 1 allocations (normal). However, future allocation for these orders is possible in
preview and simulation modes.
MM contracts cannot be allocated.
Allocation against future receipts cannot support spread logic over future receipts because of the different delivery dates in the sales orders.
Stock transfer orders are only linked as stock in the receiving plant, not in the supplying plant

!--a11y-->

Consequences of Changing Sales Orders


Use
The allocation function in sales order maintenance treats future receipts like normal stock. Allocation and deallocation processes are the same for all types of
stock, including future receipts. So if the confirmed quantity is decreased, the corresponding assignments will be adjusted. If critical data is changed (material
or size), the corresponding assignments will be deleted completely. Changes in the confirmed date can also cause a deallocation.
If the planned future receipt date runs out of scope due to one of the above changes, the corresponding assignments are deallocated.
When you deallocate a purchase order, all allocated sales orders will be locked. If one sales order cannot be locked, the system generates an error message.
The purchase order can only be processed when the locked sales order is unlocked. If the quantity is reduced and a sales order cannot be locked, the next
sales order will be deallocated.

Integration
Deallocation Rule
Whenever a change is made to a material, size or plant in a sales order, the stock is always deallocated. However, in Customizing for Sales Orders, you can
specify whether or not changes to the following fields in a sales order will automatically result in deallocation:
Storage location
Requirement category
Batch
In addition you can define safety windows for each stock type for deallocation. If a schedule line delivery date changes so that the new confirmed date does
not match the safety window of an allocated stock type, all corresponding assignments are deallocated.

Sort Rule
In ARun Customizing for sales orders, you can define how the system sorts assigned stock when performing deallocations. For example, if you want to sort
first by MRP status, then by stock type, then by schedule line confirmed date, you would make the following entries:
Sort field

Priority

J_3ASTAT

J_3ABSKZ

EDATU

Sort descending

By selecting Sort descending flag, you can reverse the sort order for a given field. For example, if you check this field for the allocation run number (ARUN),
the system deallocates the most recent assignments first.

Release Rule
In Customizing for ARun handling of SD documents, you can assign certain release rules for different types of sales documents.
If you have an existing sales order schedule line to which future receipts have already been allocated, subsequent changes to the sales quantities can affect
allocation status. To avoid this, the Release Rule field provides a second release rule check after changes have been made to a sales document. The
system runs this check when the sales document is changed and saved. The field is not specific to future receipts only.
If you have assigned both an ARun type plus a special release rule to a sales document type, the special release rule always would overrule the release
check rule of the ARun type.

Suppose you have a requirement for 100 pieces. The release rule for the customer is 80%. During an allocation run, the system finds batch
stock of 80 pieces and it allocates them to the requirement. Because 80 pieces are sufficient, the allocation passes the release check and
gets the Fixed MRP status (F).
Sometime after the allocation run, the sales quantity in the sales order is increased to 120 pieces. If there were no subsequent release rule
checks, the order would be scheduled for delivery, even though 80 pieces is no longer sufficient to meet the 80% requirement. However, the
system does check the release rule again and sees that 96 pieces are needed, not 80. This time it fails the release check and therefore the
MRP status of the allocation changes to Reserved(R).
!--a11y-->

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 26 of 49

Consequences of Changing Purchase Orders


Use
The standard strategy is as follows:
Changes in the basic criteria (material or size) will completely deallocate the corresponding assignments.
Changes to date-sensitive data by more than x days (for example, postponing the expected goods receipt date) will completely deallocate the
corresponding assignments if it would cause the planned goods receipt date to move outside the safety stock window. Alternatively, you can activate the
acceptance check flag: if the acceptance test fails, the affected (or all) requirements will be deallocated. For example, if a goods receipt date is postponed
from June 10 to June 20 and the acceptance test flag is set to E (error), then all assigned sales order schedule lines with a confirmed date prior to June
20 will be deallocated.
Changes to storage location or stock category can lead to a deallocation.
Decreasing the ordered quantity will result in a deallocation. You can configure the system to determine whether all related assignments should be
deallocated or only assignments up to the reduced quantity (in total). The latest requirement will be the first one to be deallocated. Alternatively, you can
assign a sorting rule to give the certain assignments a priority (as in ARun sorting); in this case, you can have the system deallocate the lowest priority
assignments first.
When you deallocate a purchase order, all allocated sales orders will be locked. If one sales order cannot be locked, the system generates an error
message. The purchase order can only be processed when the locked sales order is unlocked. If the quantity is reduced and a sales order cannot be
locked, the next sales order will be deallocated.

Integration
Plant-Dependent Rule
In ARun Customizing for PO handling, you can select the following plant-dependent rules:

Logging rule
This determines the log file rule to be used for actions taken by the system during PO handling. You can configure the log file rule in Customizing for Log
File Rules (IMG path: AFS Allocation Run ARun Detail Log Logfile Rule .
Deallocation rule
This determines the circumstances under which deallocation may or may not be permitted. (See the description of Deallocation rule below.)
Sort rule
This determines the order in which requirements are to be deallocated, if deallocation is needed. For example, deallocate the least important orders first,
or deallocate by ascending sales order number, and so on. (See the description of Sort rule below.)

Deallocation Rule
In ARun Customizing for PO Handling, you can define deallocation rules to be used when purchase orders are changed. If you want to prevent critical data
from being changed, you could lock purchase orders before scheduled delivery so that no changes can be made.
On the other hand, if you allow changes but want to send a warning whenever someone changes a purchase order quantity, you can choose Warning before
deallocation in the check fields.
In conjunction with the Quantity field, the Complete sched . field determines whether the entire quantity for that schedule line is automatically deallocated.

For example, if you decrease a schedule line quantity from 100 to 75 pieces, then:
If the flag is off, 25 pieces will be deallocated
If the flag is on, the entire 100 pieces are deallocated
For each of the fields on the screen, you can select from the following actions:

Change not permitted


Warning message before deallocation
Deallocation without issuing a warning message
No action

If you select No action for any field, then the system will allow the change and take no other action. For example, if you choose No action for Storage
location , then if a buyer changes the storage location in a purchase order for a given material, the system simply handles the purchase order as it normally
would.
The DCI, Deletion indicator , and Quantity fields do not have a No action entry. These fields are critical to purchase order handling and you must decide how
you want the system to react.

Sort Rule
In ARun Customizing for PO Handling, you can define how the system sorts requirements, stock, and other objects when performing deallocations.

For example, if you want to sort first by MRP status, then by delivery priority, then by schedule line confirmed date, you would make the
following entries:
Sort field

Priority

J_3ASTAT

LPRIO

EDATU

Sort descending

By selecting Sort descending flag for the delivery priority (LPRIO), the system deallocates the least important orders first.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 27 of 49

!--a11y-->

Consequences of Changing Production Orders


Use
The standard strategy is as follows:
Changes in the basic criteria (material or size) will completely deallocate the corresponding assignments.
Changes to date-sensitive data by more than x days (for example, postponing the expected goods receipt date) will completely deallocate the
corresponding assignments if it would cause the planned goods receipt date to move outside the safety stock window. Alternatively, you can activate the
acceptance check flag: if the acceptance test fails, the affected (or all) requirements will be deallocated. For example, if a production goods receipt date is
postponed from June 10 to June 20 and the acceptance test flag is set to E (error), then all assigned sales order schedule lines with a confirmed date prior
to June 20 will be deallocated.
Changes to storage location or stock category can lead to a deallocation.
Decreasing the ordered quantity will result in a deallocation. You can configure the system to determine whether all related assignments should be
deallocated or only assignments up to the reduced quantity (in total). The latest requirement will be the first one to be deallocated. Alternatively, you can
assign a sorting rule to give the certain assignments a priority (as in ARun sorting); in this case, you can have the system deallocate the lowest priority
assignments first.
When you deallocate a production order, all allocated sales orders will be locked. If one sales order cannot be locked, the system generates an error
message. The production order can only be processed when the locked sales order is unlocked. If the quantity is reduced and a sales order cannot be
locked, the next sales order will be deallocated.
When you mark a production order as technically complete, assignments for production order are deallocated.

Integration
Plant-Dependent Rule
In ARun Customizing for PP handling, you can select the following plant-dependent rules:

Logging rule
This determines the log file rule to be used for actions taken by the system during PO handling. You can configure the log file rule in Customizing for Log
File Rules (IMG path: AFS Allocation Run ARun Detail Log Logfile Rule .
Deallocation rule
This determines the circumstances under which deallocation may or may not be permitted. (See the description of Deallocation rule below.)
Sort rule
This determines the order in which requirements are to be deallocated, if deallocation is needed. For example, deallocate the least important orders first,
or deallocate by ascending sales order number, and so on. (See the description of Sort rule below.)

Deallocation Rule
In ARun Customizing for PP Handling, you can define deallocation rules to be used when production orders are changed. If you want to prevent critical data
from being changed, you could lock production orders before scheduled delivery so that no changes can be made.
On the other hand, if you allow changes but want to send a warning whenever someone changes a production order quantity, you can choose Warning before
deallocation in the check fields.
In conjunction with the Quantity field, the Complete sched . field determines whether the entire quantity for that schedule line is automatically deallocated.

For example, if you decrease an assembly SKU quantity from 100 to 75 pieces, then:
If the flag is off, 25 pieces (header assembly SKU) will be deallocated
If the flag is on, the entire 100 pieces (header assembly SKU) are deallocated
For each of the fields on the screen, you can select from the following actions:

Change not permitted


Warning message before deallocation
Deallocation without issuing a warning message
No action

If you select No action for any field, then the system will allow the change and take no other action. For example, if you choose No action for Storage
location , then if a buyer changes the storage location in a production order for a given material, the system simply handles the production order as it normally
would.
The DCI, Deletion indicator , and Quantity fields do not have a No action entry. These fields are critical to production order handling and you must decide
how you want the system to react.

Sort Rule
In ARun Customizing for PP Handling, you can define how the system sorts requirements, stock, and other objects when performing deallocations.

For example, if you want to sort first by MRP status, then by delivery priority, then by schedule line confirmed date, you would make the
following entries:
Sort field

Priority

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Sort descending

Page 28 of 49

LPRIO

EDATU

By selecting Sort descending flag for the delivery priority (LPRIO), the system deallocates the least important orders first.

!--a11y-->

Consequences of Changing Confirmations


Use
You control how the system reacts to confirmation changes by making settings in Customizing for Purchase Orders.

Integration
The following transactions are used for confirmations:
ME22N/ME22N for creating/changing purchase orders
VL31N/VL32N for creating/changing confirmations
Confirmations must be goods receipt relevant.
Whenever you enter a shipping notification, the system copies the amount contained in the shipping notification to the schedule lines in the sales order.

For example, suppose you have a sales order for 1000 pieces and you assign a purchase order for 1000 pieces to it. You then receive a
shipping notification for 600 pieces. In this case, the system assigns 600 to the sales order schedule line and decreases the amount in the
purchase order by the same amount. The purchase order now reflects only the outstanding 400 pieces.
When the system creates these assignments, it compares the schedule line date (EDATU) to the confirmation date (EINDT). It then checks the deallocation
rule in ARun Customizing for Purchase Orders. If the difference between the two dates exceeds the No. of days setting in the deallocation rule, the system
either proceeds with the deallocation, generates an error or warning message, or takes no action. If the goods receipt date of the confirmation does not match
the safety window, the system will not make any assignments for the confirmed quantity (confirmation). See the deallocation rule discussion in Consequences
of Changing Purchase Orders.
Similarly, whenever you change a confirmation, the system compares the dates before and after the change and again checks whether the new planned goods
receipt date is still within the confirmation safety window.
If you delete a confirmation, the system removes the quantity of the shipping notification from the sales order schedule line and restores it to purchase order.

You have a sales order for 1000 pieces and a purchase order for 3000 pieces assigned to this sales order. You receive the following shipping
notifications (SN):
SN1: 800 pieces
SN2: 300 pieces
SN3: 1900 pieces
The first 800 pieces from SN1plus 200 of the 300 pieces from SN2 are assigned to the sales order.
If you now delete SN1, the system would restore the allocations to the purchase order in case the restore flag in the deallocation rule
customizing is checked. Hence, the allocations to the sales order would be:
PO : 800
SN2: 200

!--a11y-->

Consequences of Changing Goods Receipts Dates


Use
At time of goods receipt, one of several scenarios may occur:

Complete delivery
Partial delivery
Partial delivery with DCI (delivery complete indicator)
Late delivery (for example, past the cancellation date)
Complete delivery, but materials are different from those originally ordered (for example, change of category)

The standard allocation strategy depends on a determination table. A BAdI is available if individual parameters are required (for example, if certain materials or
customers will always be completely deallocated).
The standard strategy includes the following options:

Batch horizon
Batches are only accepted if the confirmed date minus the goods receipt date (todays date) is less than the batch horizon.
Storage location, batch number , DCI (delivery complete indicator)
If you activate these checks, the system will deallocate the corresponding assignment whenever the check fails (for example, stock is not available in the

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 29 of 49

storage location you requested).


Sort rule
In case of a deallocation, for example, those requirements with the latest open-to-deliver date will be deallocated first.
Exception handling
The system generates exceptions when it encounters problems during goods receipt so you can review them afterwards.

!--a11y-->

1.1.7 Release Check


Use
As there is often a long period of time between the order entry and the allocation, quantities that have been confirmed by the availability check during the order
entry might have changed. When the confirmed delivery date is reached, there are often fewer goods available than had been confirmed. This material
shortage is caused by underdeliveries and/or delayed deliveries.
You use release check rules to determine which quantities are acceptable for your customers. That means which minimum/maximum percent of the quantities
must be fulfilled at the different release levels so that an order can be released for delivery.

Integration
You can define Release Rule for:
Specific Temporary groups
Specific customers
Specific sales orders
Allocation Run types (global release check rule)
You must define a Release Rule for each Allocation Run type. The system uses this Release Rule if there is no valid Release Rule for the temporary group or
for the customer. If there are several valid Release Rules, the Release Rule of the group has the highest priority, that of the customer has the next highest and
the Release Rule attached to the Allocation Run Type has the lowest priority.
To control the release check rule determination, maintain the determination logic parameters in each ARun type.
You can define the different release checks for different release check levels. The system uses a bottom-up strategy, which means that the check starts at
the lowest level and then goes to the next higher level.

At the end of the release check rule, you must define how the allocated and still open (remaining) quantities should be handled. This final action is connected
to the action rule and the reallocation rule (see Fill-Up).
Release checks can also be defined for value-added services and bills of materials. You can find the procedure in the IMG node Define Release Rules for
Special SD Functions .

Example
The checks in the release check rule proceed as follows:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 30 of 49

Since only 5 pairs of shoes of the 10 ordered pairs in size 38 are available (50%) and the release check rule is not fulfilled with a minimum quota of 60%, the 5
pairs of shoes are not allocated at schedule line level. The system then checks at item level whether a minimum quota of 70% can be reached. As in this
case only the 10 pairs of shoes in size 36 can be passed on to the next release check level, the release check fails here as well. As a result, no pair of shoes
can be passed on to the order header level. That means that the entire order cannot be allocated because the release check at header level fails as well (only
24 shoes are available, which is 48% of the total order quantity).
If the stock of the shoes in size 38 is increased by one pair, that means 6 pairs of shoes are available, the entire order can be allocated.
Excluding Allocations with Status D and F from the Release Check
With this function you can change the basis of the release check calculation and adapt it to the appropriate business process. To do this, use the calculation
base parameter in the ARun type.
Special ARun Release Check Rules for Sales Orders
You can assign a specific release rule that is only valid for specific sales orders. The release check rule is then stored in the order header. The release check
rules are determined or put into sequence using the determination logic in the ARun type.
The ARun release rule options are defined as follows:
Option

Description

1: Global release rule

Checks all requirements selected by ARun with the same release check rule

2: Customer-specific release rule

Uses a separate release rule for each customer to check all sales order
requirements for that customer

3: Order-specific release rule

Uses a special release rule to check requirements for an individual sales order

The following are possibilities for setting up release rule determination:


Entry

Release Check Rule / Release Check Sequence

Blank

Always use the global release check rule

1. Use the rule in the sales order


2. Use the global release check rule

1. Use the rule in customer master


2. Use the global release check rule

1. Use the rule in the sales order


2. Use the rule in customer master
3. Use the global release check rule

!--a11y-->

Release Check for Schedule Line Groups and Delivery Groups


Use
Customers may demand that a minimum required percentage of an order be included in their shipments. For example, a customer has a standing order for 10
pallets each of T-shirts in different sizes delivered monthly. But if less than 60% of the total order is available for a given month, the shipment should be
delayed until that minimum quantity is met. This 60% is considered the release quantity the minimum amount needed before goods can be released for
shipment.
You can assign one or more schedule lines to a schedule line group. Likewise, you can assign one or more items to a delivery group. You can define these
groups however you wish; for example, schedule line group 1 might be for the customer's highest priority goods or best sellers. For goods that are not as
critical, you may not assign a schedule line group at all. If you do not assign a schedule line group indicator to a schedule line, the system automatically

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 31 of 49

assigns it group 000.


When ARun is calculating the release quantity, you can specify whether it should take all schedule lines into account, or only those schedule lines, which are
assigned to schedule line groups. The same is true for delivery groups.

Schedule line groups are always at the schedule line level.


Delivery groups are always at the item level.

Integration
When ARun is calculating the release quantity, you can specify whether it should take all schedule lines into account (the default), or only those schedule lines
which are assigned to groups. To accomplish this, maintain the Ignore blank linegroups field in Customizing for release rules. There is a similar field for
delivery groups: Ignore blank deliverygroups.

Example
Suppose you have the following customer order, with a 60% release quantity requirement for the entire order:
Order

Material

Item

Schedule line

Size

0815

TS01

10

001

002

003

004
001

TS02

20

Schedule line
group

Required quantity

Available quantity

10

10

10

XL

10

10

10

002

10

003

10

10

004

XL

10

10

If blank schedule line groups are included :


In the order, material TS01 medium and large plus material TS02 large and extra large all have the same schedule line group number, so they are
considered together for fulfillment. Schedule line group 001 has a fulfillment of 70% (3+5+10+10=28/40), so the release percentage is met and all
schedule lines of this group will have status F (fixed assignment for release).
For all other schedule lines there is no schedule line group maintained, therefore they are treated as one group: 000. The fulfillment of schedule line group
000 is 53% (5+10+5+1=21/40) and therefore will not be released.
As a result, only a part of the order can be shipped.
If blank schedule line groups are omitted :
ARun will ignore all schedule lines without a schedule line group. For these schedule lines there will be no release check at the group level. In the above
example, only schedule line group 001 will be checked for fulfillment. Because the release percentage is met (70%), these schedule lines will have status
F (fixed assignment for release).
Schedule lines without a group are not checked for release quantity, so they automatically have status F.
As a result, the entire order can be shipped.

!--a11y-->

1.1.7.2 Cancellation and Season Release


Use
Customers may include a cancel date in their orders, beyond which date they will no longer accept shipments. This information is stored in the Cancel Date
field within the sales orders. You can configure the ARun Optimizer to prevent the automatic release of an order if the estimated shipping date would occur
after the cancel date.

Assume you have received Order 123 from one of your customers.
Wednesday: You execute an allocation run. Order 123 is fully allocated and ready for shipment. However, you do not create deliveries
immediately. Instead, shipments are held up.
Friday: This is the cancel date in Order 123.
Monday: You create deliveries for Wednesdays allocated stock. Order 123 is included, even though it has passed the cancel date.
You want to make sure the system detects this situation and either cancels the order automatically or warns the customer service
representative to take action
The same is true for out-of-season goods. The system can check to make sure that materials are not shipped beyond their valid season dates. It can also
check the confirmed shipping date for the sales order item.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 32 of 49

Prerequisites
In Customizing for the ARun Optimizer, you can configure the system to carry out checks for cancel dates, season-end dates, and confirmed dates. These
checks will be performed for all schedule lines when you enter an allocation group. If a schedule line fails a check, the system stores a message and displays
an icon each list level. This lets the customer service representatives see that at least one schedule line on the current level failed a check.
The Customizing path is AFS Allocation Run ARun Optimizer ARun Optimizer Control Configure ARun Optimizer Type . Here you can
assign an allocation rule to the ARun Optimizer type. If you have maintained the aforementioned checks in the allocation rule, the system will perform these
checks in the ARun Optimizer.
For each of the data settings, you can specify:
The number of days away from the delivery date that ARun should perform the date checks. For example, if this field contains 5 and you execute an
ARun today, ARun flags all schedule lines that have cancel dates and where todays date is within this horizon (that is, there are 5 or fewer days
between today and the cancel date). If you leave this field blank, the ARun only checks to see whether the cancel date matches the current date.
Whether or not schedule lines that fail the date check should be automatically excluded from allocation. If you flag failed schedule lines to be excluded,
the release check does not consider the corresponding allocated quantities in calculating fulfillment. In addition, the result of a release check does not
impact the excluded assignments. For example: if the release check succeeds, only the included assignments are released; the excluded ones keep
their previous MRP status.
The type of message the system should display (red or yellow traffic light) if a schedule line fails the check. If you leave this field blank, the check is
turned off.

!--a11y-->

1.2 Execution of an Allocation Run


Use
You can carry out an allocation run both in the background and online. This topic describes what you should note during the execution of an online allocation
run. The background processing of allocation runs is described in another section.

Features
An allocation type controls every allocation run. All the rules that influence the allocation run are grouped in the allocation type. The individual rules, such as
the release check or the requirements sorting, are individually defined in Customizing of the allocation run and entered in the corresponding allocation type.
Since you can define any number of allocation types, you can map a very wide variety of business processes in the system. For example, you can create
special allocation types with specific settings for certain customers. That way you can make sure those special requests can be mapped by the system during
the sales order processing.
Each time you start an allocation run you can decide in which mode the run should be carried out. You can choose the normal mode that actually carries out
allocations, the simulation mode that shows the currently possible allocation results, or the preview mode that allocates existing orders against future
stocks.
Every allocation run is controlled using an allocation type. The rules that are stored in the allocation type determine how the allocation is carried out. Before
you start an online or dialog allocation run, you can decide whether the settings of the allocation type will be completely transferred or whether certain
parameters of the release check and the stock/requirements sorting should be overwritten. It is therefore not necessary to redefine allocation types if there are
only short-term changes. In addition you can make settings in Customizing for the release check. You can do that in the menu of the allocation run. You can
also make temporary changes without directly branching to the IMG.
You can display the results of a saved allocation run anytime via the ARun Optimizer and the log files. With the aid of the log files you can also
subsequently check which settings were used during the execution of an allocation run.

Activities
1. If necessary, define an allocation type in Customizing for the allocation run.
2. In the SAP Easy Access screen, choose Logistics

Allocation Run

Online Processing.

3. Choose an allocation type to determine which rules should be used for the execution of the allocation.
4. Determine in which mode the allocation should be carried out.
5. Enter a description for each allocation run. You can use it as search help during later evaluations via the ARun Optimizer or the log files.
6. Determine whether the allocation run should be carried out according to the rules that are entered in the allocation type or whether you want to overwrite
individual parameters of the release check or the stock/requirements sorting.
7. Choose Execute to start your allocation run.
8. Save your allocation run.
9. If you want to subsequently check the settings of an executed allocation run, you can branch to the log files from the overview screen Online Processing .

!--a11y-->

1.3 Parallel ARun Execution


PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 33 of 49

Use
Performing an allocation run can be resource intensive if a large number of sales orders are involved, as is usually the case. This function allows you to start
multiple processes in parallel across several servers to shorten the run time and also to distribute system resources more evenly.
You start one ARun on one server for your entire allocation run, but this main program triggers parallel tasks on multiple application servers. Each task
processes the requirements for a single material across all selected sales orders, and then runs the allocation and relevant release steps for these
requirements.

Integration
The following table indicates which functions are performed by the main program, and which are executed by each of the parallel tasks:
Function

Performed by main ARun program

Performed by each parallel ARun task

Prepares and triggers the parallel tasks

Yes

--

Preselects relevant sales order requirements

Yes
(Splits up the selected sales order requirements and
assigns them to the various tasks)

Yes
(Processes all sales order requirements for one
material assigned to it by the main program)

Filters out sales orders that fail to meet ARun type


check rule

--

Yes

Performs allocations

--

Yes

Performs release checks for item level and below

--

Yes

Collects the allocation results from each task

Yes

--

Performs final release checks above item level

Yes

--

Determines MRP status (for example, fixed or


reserved)

Yes

--

Stores the results in the database

Yes

--

During the preselection of relevant sales orders, the main program determines how often a given material appears across all sales orders (that is, the number
of times the schedule line item appears, not the actual quantity specified within the order). The main program then assigns the most frequently ordered
material to the first task, the next most frequently ordered material to the second task, and so on.

Activities
You create one ARun on one server for your entire allocation run, but this one report triggers parallel tasks on multiple application servers.
You can specify whether you want to use:
A particular group of application servers
All available servers
You can also specify the number of work processes to be started for a server group on the specified application server. If you leave the field blank or enter 0,
it indicates that there are no restrictions for the number of work processes that can be started.
If the maximum number of parallel tasks is reached, the program waits for a task to finish, then starts another task on that same server. If a parallel task
cannot be started (for example, due to system overload or to a server being unavailable), the system generates an error message.
Use transaction RZ12 to create server groups. This determines which application server and instances will be used by the transaction.
You can also run program /AFS/ARUN_RFCLST_DISPLAY to analyze a parallel allocation run. When you enter an allocation run number, the program displays
the application servers used by the ARun, along with the start and end times, the RFCs involved, and total requirements. In addition, there is a value given for
the workload -- sum of the runtimes of all the work processes that were started. You can drill down to see all details of a particular work process.

It is recommended that you also run program /AFS/ARUN_RFCLST_DELETE to delete results of older ARuns in order to reduce data volume.

Restrictions
You do not receive statistical information as you do with the standard ARun function.
Parallel ARuns cannot perform dynamic credit checks.
Parallel ARuns cannot handle value-added services, which require additional physical VAS materials (such as hangers, special labels and so on) because
these materials are separate stock that cannot be allocated together in parallel. If there is a shortage of the required VAS material for a given schedule
line item, ARun must be able to adjust the quantities so that they match.
For example, suppose a branded polo shirt comes with a separate logo to be sewn on. You have 10 shirts but only 9 labels. Since separate work processes
in parallel ARuns allocate both materials, the system is unable to reconcile the differences.
However, parallel ARuns can handle value-added services, which do not involve separate physical materials (such as stitching, screen printing and so on).
If you want to avoid these restrictions, use the standard ARun function.

!--a11y-->

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 34 of 49

1.4 Preview
Use
You can carry out an allocation run either in normal mode or in preview mode. In preview mode you can allocate existing orders against future stock (for
example, purchase requisitions, purchase orders, shipping notifications) to estimate possible fluctuations of future warehouse stock. This is an early warning
system with which you can simulate problems. That means that you can react proactively and in time.
Allocation in preview mode considers, for example, delayed goods receipts for purchase orders and possible quantity deviations and shows the effects on the
existing sales orders. Allocation against future stock can take place with either status R (reserved) or F (fixed):
Use ARun preview mode 2 to test for status R. The resulting stock will receive status R, even if all checks (for example, release check, cancel date check,
or season check) are successful. The disadvantage is that you do not know whether the system assigned status R because of stock availability or because
one of the allocation checks failed. The system will not assign status F in any case.
Use ARun previous mode 4 to test for both status F and R. In this case, the system will return status F if all checks are passed successfully and it is able
to properly match the stock with a future receipt, and status R otherwise. This mode gives you more detailed information for confirming expected delivery
dates for a customer.
For example, if you have future order 123 for material X with a delivery date of May 15, and the stock will be available as of May 12, preview mode 2 returns
status R, while previous mode 4 returns status F.
In addition, there is a check and a comparison of the confirmed date of the sales order with the goods receipt date from various purchase orders and/or
purchase requisitions, so that the best possible delivery date can be found.

Order 1 Material X Confirmed Date December 24, 2001


Purchase Order A Material X Delivery Date December 31, 2001
Purchase Order B Material X Delivery Date December 20, 2001
Purchase Order C Material X Delivery Date January 5, 2002
The purchase order that would be assigned stock by the ARun preview would be purchase order B, since it meets the confirmed date of the
order best.
Preview mode can be used either online via dialog boxes, or in background processing.

Integration
It is better to run the preview modes before the allocation in the normal mode. In the system, however, they are independent of the normal mode. The process
in the application is identical. When starting the allocation you need only enter the corresponding mode.
You do not need to make any special Customizing settings for preview mode. You select which of the modes you want to use when you start an allocation run.

Features
The results of the allocations in the preview mode are saved in a special database and you can evaluate them by using the ARun Optimizer. There is no
update of the real requirements and stock. That means you cannot create deliveries, for example, on the basis of an allocation in the preview mode. The
fixations or reservations are only simulated. An update is only possible with an allocation in the normal mode.
The allocation type you use for allocation in normal mode can also be used in preview mode. However, in this case future stock and goods receipts are not
taken into account. For this reason, you should create a special allocation type to be run only in preview mode.

!--a11y-->

1.5 Fill-Up or Reallocation


Use
Using the fill-up feature, you can reserve orders that cannot be allocated because of the current stock/requirement situation until the corresponding release
check rules are fulfilled. Thus you can make sure that the stock is not available for the coverage of other requirements after a failed release check.

Integration
Fill-up needs an action rule to keep allocations in spite of a failed release check. The action rule requires the reallocation rule so that already existing
allocations (for example reservations) are included in a new allocation run. In the release rule you must also define what should be done with the allocated and
open quantities. The allocation status is a combination of the allocated and open quantities, the allocation event, and the MRP status.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 35 of 49

Prerequisites
For a fill-up, the relation between the relevant Customizing settings and the corresponding rules, checks and status could be as follows:

Case

Customer

Check in the

Determination

Release Rule

Rule

Final Action

Release check

MRP Status

ARun Event

ARun Status

passed?

VIP

100% E at order
header level

yes

M
K

Yes,
No,

R
R

Blank
E

XMKR
EMKR

Normal

80% E at order

Standard release R

Yes,

Blank

XRDF

header level

rule of the
allocation type

No,

ERDR

90% E at order
header level

Yes

A
K

Yes,
No,

F
R

Blank
E

XAKF
EAKR

Special

M* = reserved, manual release via the ARun Optimizer is required


R* = reserved for automatic delivery creation
A* = reserved, will be automatically released in the next allocation run
E* = failed because release check could not be fulfilled

The example is based on the assumption that there are three classes of customers:
The VIP customer such as a key account customer should always get the total quantity they have ordered. In addition, the release should not be carried
out automatically, but only manually via the ARun Optimizer. This customer has their own release rule that is defined using the determination rule and
release strategy and which deviates from the global release rule of the allocation type. There are no open quantities after an allocation run because the
customer should always get 100% of the ordered quantity.
The normal customer is usually satisfied with 80% of the total order quantity. After the passed release checks, the stock is automatically released. The
20% that may not yet have been allocated should not be processed as an open requirement for this customer and is therefore dropped.
The special customer orders almost every day and thus receives the deliveries frequently. Today the customer orders a larger quantity that you cannot
completely allocate. Since you know that you can expect the next order of this customer tomorrow, you assign the available quantity (must be at least
90%) to this customer and keep the remaining open quantities. The order is first released with the next (tomorrows) allocation run (vendor managed
inventory).

Integration
For fill-ups, if a material fails a release check at one level, you can control whether the failed quantities are considered when calculating the release percentage
at the next higher level. For example, quantities that are insufficient at the schedule line level will not be included in the release percentage calculation at the
item level (one step above the schedule line level). You specify In Customizing for allocation types whether the system considers or ignores materials in
calculating the release percentage.

Suppose you have the following sales order. There is a 60% release check at the schedule line level and a 70% release check at the item
level.
Material

Schedule line

T-shirt XL

T-shirt L

Required quantity

Available quantity

Pass/fail release check


at schedule line level

10

10

10

Pass
Fail

10

10

Pass

10

Fail

- If the system then considers the failed quantities for the item level release check, there is a 65% fulfillment for the first material (13 of 20)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 36 of 49

and a 75% fulfillment for the second material (15 of 20). So the first material still fails the item level release check and therefore receives a
status R (reserved), while the second material passes and receives status F (fixed). Only the second material will ship at this point.
- If the system ignores the failed quantities for the item level release check, there is only a 50% fulfillment for each of the two materials (10 of
20) In this case, both materials fail the release check, receive status R, and neither one will ship.

Remember that requirements and their related reservations remain in the system. That means that you must reject them at the end of the
season, as long as the required minimum quantities could not be reached and replenishment is not possible. On the other hand, you might
have to release the reserved minimum quantities using the ARun Optimizer because otherwise you cannot create deliveries and the orders
would be displayed as open in the system.
You must use logic 1 for the automatic reallocation, which is the automatic reading of possibly existing reservations ( R ).

!--a11y-->

1.5.1 Action Rule


Use
Using the action rule, you can determine that in certain circumstances, you can assign requirements to stock (you can reserve them) despite failed release
checks. Normally the assignments would be dropped because the minimum quantities are not reached.

Integration
The action rule works with the reallocation rule that is stored in the allocation type. You can fulfill stock with subsequent allocation runs until the minimum
quantities are fulfilled and the release checks have therefore been passed.

Features
The action rule consists of:
The action (that is, the reaction parameter) that controls whether the system reaction is an information message, termination, warning or error. However, it
only makes sense to use an action rule if the system reaction to a failed release check is displayed as an error.
The release object level (the level at which the release check failed). If you do not enter a level, the assigned quantities at all allocation levels are kept,
despite release checks that failed due to the allocation result.
The allocation run event. The event is relevant if the release check has failed. The MRP status for the respective partial quantity, for which batch stock is
still available, will ultimately be determined from the entries in the fields A llocated Quantity and Open Quantity and the Allocation Run Event .
The handling of assigned quantities. That means the assignment of the quantities to the requirements must be kept, even if a release check has failed.

The SAP action rule MASS causes stock to be assigned to the orders, even if the stock could not be allocated during the release checks
because of general errors. They get the MRP status R (reserved).

Activities
1. In Customizing, to define your action rule choose AFS Allocation Run ARun Detail Release Action Rule.
2. Choose Release Rule to enter this action rule in the corresponding release rule.
3. Choose Define Allocation Logic
Reallocation to define the reallocation rule and enter it in the corresponding allocation type. This step is necessary
because using an action rule without a reallocation only leads to a reservation of the stock. However, the stock should be filled with each subsequent
allocation run until the valid release rules are fulfilled.
!--a11y-->

1.5.2 Reallocation Rule


Use
The reallocation rule tells the system that existing assignments from previous ARuns should be included in the current ARun. By reading the old assignments
as well as the new ones, you increase the probability of satisfying the release check rules and therefore being able to ship goods sooner.

Suppose you have a sales order for two materials:


- 10 T-shirts, size XL
- Zero T-shirts, size L
The release rule requires that at least 60% of the stock must be available for the goods to be shipped. You have 10 of the XL shirts, but none
of the L shirts. Since only 50% of the material for the sales order is available, the allocation run assigns the XL shirts status R (reserved), but
the overall sales order fails the 60% release check rule and therefore does not ship.
Sometime after the ARun, you receive five L shirts into inventory. In the subsequent ARun, the system now finds the old 10 XL shirts plus the

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 37 of 49

new 5 L shirts, at total of 15 shirts of the 20 ordered. To fill the order now 75% of the stock is available. It passes the release check and the 15
shirts will be shipped.

Integration
The reallocation rule works together with the Action Rule. If you are using the fill-up strategy, you must activate the final release check in Customizing for the
allocation type.

Features
The reallocation rule consists of the following:
Allocation logic specifying that the reserved quantities (that is, the old allocations which have MRP status R) are to be read again before the release check.
It also determines whether the Reallocation icon appears on the allocation list screen (for allocation runs that are started online via a selection screen
rather than in the background). Also, for each allocation run, you can choose whether to have the system include:
o All assignments
o Only those assignments matching the selection criteria. This allows you restrict the reallocation, for example, to one or more materials in an existing
sales order.
The Allocation Event.
The reservation status of the allocated quantity. This must have been previously defined as final action in the corresponding release rule. (For further
information, see Release).
The MRP status. You can specify whether the system consider only old, reserved assignments with MRP status R, or fixed assignments with status F.
Currently the selected status is read separately from the allocation event and the reservation status of the allocated quantities.

Activities
1. In the Customizing, to define your reallocation rule, choose AFS Allocation Run ARun Detail Define Allocation Logic Reallocation . Specify
whether you want to include all assignments or, only assignments matching the selection criteria.
2. In the Customizing, choose ARun Type and enter the reallocation rule in the corresponding allocation type. You can access the ARun Type by either
of the following navigation paths:
AFS Allocation Run ARun Detail ARun Type
AFS Allocation Run ARun Optimizer ARun Optimizer Control ARun Type
!--a11y-->

1.6 ARun Optimizer


Use
ARun Optimizer is an online tool for viewing and managing post-ARun allocations. It enables you to quickly locate areas that are likely to fail release by
displaying real time allocation release percentages and stock allocation details (for example, which quantities are reserved, fixed, on delivery or open) at
different levels.
In combination with Allocation Against Future Receipts, The ARun Optimizer provides early visibility at the complete order level and so that you can quickly
spot potential delivery problems and respond appropriately

Integration
Using the ARun Optimizer you can manually change or reset the results of the allocation run. This way you can react to a changed stock and requirements
situation any time after the allocation run. You can change undesired allocation results. If you use the fill-up, for example, it might be necessary to use the
ARun Optimizer. The MRP Status R must be changed with the aid of the ARun Optimizer so that a reserved quantity can be released for delivery in the further
procedure.
You can use the ARun Optimizer in the online mode only. If you want to process large volumes of data, it is recommended that you use Background
Processing with the aid of Reorganization.
With the ARun Optimizer, you can manually select and change individual assignments. If the results of a complete allocation run should be changed, it is
recommended that you use Reorganization.

Prerequisites
You must maintain the IMG settings for the AFS Allocation Run .

Features
With the ARun Optimizer you can change allocation results. It is possible to change the MRP status of individual assignments. The changes only affect
statuses that have been directly created by an allocation of the allocation run. That way a reserved item can be manually released for delivery at SKU level.
On the other hand, released items can be reset to reserved status.
You can reset Individual allocation results manually, if necessary, due to a change in the stock or requirements situation of a material. The now unrestricted

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 38 of 49

stock is again available for a new allocation to other sales orders.


You can redistribute allocated quantities within an allocation group. For example, an allocation group for a certain customer has 4000 store orders with
reserved stock. Zero orders are releasable for delivery using an even spread of stock. However, after calling the customer and using FIFO redistribution, you
can now deliver stock to 2000 stores.
You can start the ARun Optimizer in all modes of the allocation run in which an actual allocation occurs and the allocation result is saved (normal and preview
mode). As no physical allocation of stock occurs during the allocation run in simulation mode, you cannot use the ARun Optimizer in simulation mode.
Using ARun types you control which parameters are used by the system to select the allocations and which data is displayed in the result screen. This way
you can predefine different ARun Optimizer runs with individual settings for different processes and users and you can adjust them to meet the respective
requirements.
Using dynamic selection you can determine the appearance and the content of the output screen of the individual ARun Optimizer types. Thus you control
which fields are displayed from which table in the result screen of the ARun Optimizer. This makes it possible to display user-defined fields as well.
In the ARun Optimizer, orders, materials, and dimensions are flagged with a priority and a stock limit and/or special release percentage for special allocation.
This enables pinpoint management of short or hot products for your high priority customers. Flagged orders have a much higher probability of allocation in an
ARun timed to run after goods receipt(s) just for these orders, but this has no impact on physical inventory or ATP, MRP, and so on. ARun allocates flagged
orders up to limits specified by the user.

!--a11y-->

1.6.1 Rejecting Open Quantities


Use
You can configure the allocation run (ARun) to drop unallocated quantities on release and assign a rejection code. You can also do this in the ARun Optimizer,
where you have some additional options.
ARun
You can only flag schedule lines for rejection. You subsequently run the SD Mass Document Change Report (/AFS/RVMDCD) to reject the schedule lines.
ARun Optimizer
You can flag orders, deflag them subsequently or reject the quantities immediately. In case of flagging and deflagging orders, the results have to be
saved. However in case the reject immediate option is used, rejection takes place prior to saving and the process cannot be undone thereafter.
Each rejection code is configured to reject one of the following:
o Complete quantity
o Quantity not delivered
o Quantity not allocated
In case the rejection code is configured for Quantity not allocated the rejection would work in the following manner. A partially allocated schedule line
would be divided as the allocated and unallocated portions. Further on, the unallocated portion would get rejected.

You have an order for 10 pieces. You only have 8 in inventory. The customer tells you to ship the 8 available pieces and drop the rest. The
system creates two schedule lines:
The first schedule line contains the 8 pieces to be allocated.
The second schedule line contains 2 pieces, plus a rejection code indicating that the customer considers the shipment of 8 as complete.

Prerequisites
In standard SD Customizing, you create rejection codes and assign your own text to them, indicating the reason for rejection. You can then apply these
rejection codes to release rules in Customizing for the ARun Optimizer. The Reason for Rejection field is only valid if the Open Quantity field contains X
(rejected). In ARun release Customizing, you must specify a rejection code if the Open Quantity field contains X.

Activities
You can reject open quantities using either a one-step or two-step process:
One-step process
You select a range of orders in the ARun Optimizer and reject them immediately. The system then drops all unallocated quantities and updates the
affected sales orders. You cannot undo the rejections within the ARun Optimizer; if you need to undo a rejection, you must do this directly in sales order
maintenance.
Two-step process
1. You select a range of orders in the ARun Optimizer. You can flag all orders having unallocated quantities. This has no actual effect on the orders; it
merely marks them for subsequent action.
2. You subsequently run the SD Mass Document Change Report to reject the schedule lines.

!--a11y-->

Redistributing Allocated Quantities Within an Allocation Group

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 39 of 49

Use
The purpose of this function is to improve the quality of the allocations (assignments or ARun results).
ARun allocates stock using a predefined strategy and parameter set (such as release rules). If there is not enough inventory to meet all the requirements,
these predefined configuration controls determine how the system handles the material shortage.
In the ARun Optimizer, customer service representatives (CSRs) can see the results of previous allocation runs. If they do not like how the system allocated
stock using the default strategy, they can select a different ARun type or configuration in the ARun Optimizer to reallocate the existing assignments and to
maximize shipments. For example, if an allocation run distributed stock evenly across the allocation group, the CSR can redistribute it using a different
strategy (such as FIFO).
Customer service representatives are likely to use this function on a daily basis.

Prerequisites
To define the default allocation strategy:
1. In Customizing, choose AFS Allocation Run ARun Optimizer ARun Optimizer Control Configure ARun Optimizer Type .
2. Choose the ARun Optimizer type you want to change and select Details .
3. In the Proposals section, select the allocation type with the allocation configuration you would like to use to obtain desired allocation results.

Activities
To redistribute allocations for a given allocation group:
1. In the ARun Optimizer, display the results of the previous allocation run.
2. Select the line with the allocation group to which you want to make changes. (Alternatively, you can drill down into the allocation group, then choose one
or more individual orders and only reallocate them.)
3. Choose Allocation Allocate .
The system displays the allocation dialog box.
4. Choose one of the following options:
Accept the default ARun type
You can optionally change the configuration for that ARun type by choosing Expand . This allows you, for example, to change the allocation logic
from FIFO to SPREAD, activate a release check other than the default, or activate/deactivate a category check. These changes are temporary; that
is, they are valid only for this ARun reallocation process and do not change the ARun type. Subsequent allocation runs using that ARun type will
revert back to the default values.
Choose a different ARun type instead of the default.
Here, too, you can temporarily change the configuration as described above.

This transaction does not support redistribution of unrestricted stock. You must first move unrestricted stock into your shared buffer, and then
proceed with the redistribution.

Example
Assume that an allocation group has 5 orders, each specifying 10 pieces of the same SKU. There are only 33 pieces in inventory. If you use an even spread
strategy, the system allocates the stock as follows:
Order

Material

Size

Requirement

Allocated

12345

Large

10

12345

Large

10

12345

Large

10

12345

Large

10

12345

Large

10

If you redistribute using a FIFO strategy, the system reallocates the stock as follows
Order

Material

Size

Requirement

Allocated

12345

Large

10

10

12345

Large

10

10

12345

Large

10

10

12345

Large

10

12345

Large

10

!--a11y-->

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 40 of 49

Executing Total Reallocation in the ARun Optimizer


Use
When you examine orders in the ARun Optimizer after an allocation run, you may find you need to execute ARun again for some requirements. Use the Total
Reallocation function in the Optimizer to do this.
Total reallocation triggers a background ARun process similar to online ARun. The system carries out complete deallocation of existing assignments and then
tries to find a better set of assignments based on the ARun type proposed in the ARun Optimizer.

Assume that you have two sales orders belonging to an allocation group:
The first sales order is to be delivered next week and has fixed assignments.
The second sales order is to be delivered this week, but has future receipt assignments that have not yet been received at your warehouse.
The future receipt assignments make this impossible because you would need batch assignments.
In this case, you can use Total Reallocation to deliver the second sales order by following these steps.
First use the ARun Optimizer to deallocate the assignments of the first sales order. This moves the fixed assignment stock to buffer stock
that will only be available for use within the ARun Optimizer.
Then execute Total Reallocation . The system displays a dialog box where you can select the ARun type. The ARun type should have an
allocation rule attached that prioritizes batch stock over future receipts. Now get the fixed assignments for your second sales order. The future
receipt assignments are now available within the Optimizer as buffer stock for other orders.

!--a11y-->

Accessing Sales Orders from the ARun Optimizer


Use
When examining orders in the ARun Optimizer after an allocation run, you may find you need to check some information in the sales order or to make changes
to it. You can branch directly from the ARun Optimizer screen to the order, make your changes, and return to the same location in the ARun Optimizer. The
system automatically refreshes the display to include the changed data.

Integration
Depending on how the levels and paths have been configured, the system displays a column with the sales order number.
Clicking on the sales order brings up the order in display mode.
Choosing the order from the Optimizer results and using:
Goto

Document

Change brings up the order in change mode

You can display sales order from any level in ARun Optimizer by clicking on the order number. However, you can only make changes to the sales order from a
level where the sales order number has been configured. Also, you can only make changes if you have accessed the sales order using the menu path Goto
Document Change . Once you are in the sales order itself, you can change anything you wish, including the material and schedule lines.
If you change a field that requires available-to-promise (ATP) or order scheduling, the system automatically branches to the appropriate transactions. Once
you save the changes, the system determines whether the allocation group for this order has changed; if so, the system will move the order or schedule lines
involved to the appropriate allocation group, or create a new allocation group if necessary. It will also update the sum of the assignments for the current
allocation group. Sums displayed for the other allocation groups in the ARun Optimizer list are not updated at time of order change unless you refresh the
quantities.

Changing data in the sales document could lead to a deallocation process in sales order maintenance. This would impact the subtotals in the
ARun Optimizer level and path as well.

!--a11y-->

Authorization for Tasks Within the ARun Optimizer


Use
You can restrict user access to the ARun Optimizer by assigning authorizations. The system carries out an authorization check at the start of the transaction.
If a user is not permitted to use a given function, the corresponding icon for that function is hidden. For example, if a user does not have the authority to
release orders, the Release icon will be missing from the screen. You can prevent a customer service representative (CSR) from allocating or deallocating
stock for another CSRs orders. You can also give a user the authority for only one ARun Optimizer type.

Standard SAP ERP System Authority Checks (CSA-Independent)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 41 of 49

You assign authorizations within standard SAP ERP system role maintenance. The following authority objects are available:
J_3A_ARMTT
This enables you to choose which tasks a user will be able to perform within the ARun Optimizer and which ARun Optimizer types he or she can use.
J_3A_CSA_S
This indicates a super user. The system does not carry out any CSA-related (Customer Service Area) authority checks for super users; they have access
to all functions in the ARun Optimizer.
J_3A_CSAST
This determines whether a user is allowed to consume unrestricted stock. If a user does not have this authority, the Stock Source field is hidden. That
user will only be able to access CSR stock.
S_TCODE
This determines whether a user is allowed to start a transaction (for example, the ARun Optimizer).
S_TABU_DIS
This gives a user authorization for all Customizing settings (for example, maintaining authority roles).

CSA-Related Authority Roles


Each CSR automatically has all the authorities needed for the CSA for which he or she is responsible. If you assign a substitute for a CSR but do not assign
an authority role to that person, the substitute will have the same authorizations as the CSR.
The user can only display allocation groups and CSAs to which he or she is assigned either as a CSR or a substitute.
If the user has authority object J_3A_CSA_S, he or she is a super user and no authority roles are checked.

!--a11y-->

Creating Custom Reports in the ARun Optimizer


Purpose
The ARun Optimizer can select allocation groups or assignments. There is one default selection report (J_3AAMS1) to pull in assignments. To select
allocation groups, you must first run this report first.
The default report for assignments ensures adequate selection based on frequently used selection criteria. However, if you need reports with different or
additional selection criteria, you can create these reports with the ARun Optimizers report generation tool.
For example, suppose that you want to include the material division and customer group 5 in the selection criteria. These fields do not appear on the default
selection screen. To accomplish this, you have to generate a new selection report including the old fields (if desired) plus the additional ones. Then you assign
this new report to the desired ARun Optimizer type.

With the ARun Optimizers report generation tool, you can create a selection report for both assignments and allocation groups.

Prerequisites
You should have a development class to which you can assign your new selection report. If you do not assign your report to a development class, the report
will be a local one and can be used only in the system where it was created.

Procedure
1. In the IMG, choose AFS Allocation Run ARun Optimizer ARun Optimizer Control Selection Report Generation.
2. Choose New Entries .
3. Enter the following data:
Application : This parameter defines the ARun Optimizer area for which the report will be used. Select assignments, allocation groups, or exceptions
(that is, assignments that match exceptions raised during the allocation run).
Set : This number is an identifier for the set of fields you will select. Enter the next available number within your application.
Description : Enter a name for your report.
4. Save your data.
5. At the left side of the screen, choose Tables/Fields .
6. Enter the field catalog (set of fields) to be used for selection screen generation. You must maintain all of the following fields:
Table Name : This is the name of the database table to be accessed. A selection field is only unique when defined together with the table name. The
generation is restricted to only a few database tables. Use F4 to find the one you want.
Field Name : Enter the technical field name. Use F4 to find the field you want. If you have already entered the table name, pressing Enter will
automatically provide a list of valid field names.
Sel : Assign a number to each field, reflecting the order in which it is to appear on the selection screen. For example, if you want the customer group
5 to appear after the material division, assign a higher number to customer group 5 than for the material division. The lower the number, the higher the
field will appear on the screen.
Search Help Name : Leave the field blank if you want the system to find an appropriate one during the screen generation. Otherwise enter a specific
help view.
7. Save your field catalog.
8. Optionally, you can simulate your selection screen at this point so that you can see what it would look like. To do this:
a. Return to the header screen
b. Select your report.
c. Choose Details .

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 42 of 49

d. Choose Simulation.
The system will create a log file of the generation process and display the selection screen.
9. In the detail screen, choose Generate Report .
10. In contrast to the simulation, the system will ask you for a report name. Enter a unique name for your new report. If a report with that name already
exists, the system will prompt you for a unique name. In this case you can either confirm the name you entered (in which case it will overwrite the existing
report) or enter a new name. The generation will finish by processing a log file.
11. To use the new selection report, you must assign it to an ARun Type ( AFS Allocation Run
ARun Optimizer ARun Optimizer Control
Selection Report Generation).

!--a11y-->

1.7 Background Processing


Use
Usually a company must manage a large volume of data in Sales. Due to a great number of incoming orders, an automatic processing within the logistical
process is required. It is advantageous to externally carry out certain collective processing in times of low system utilization.
You can carry out both the allocation of stock as well as the subsequent changes of allocation results in the background. The background processing is not
only a temporary bundling and removal of system activities, but it is also used as a control within the allocation run. By specifying the temporal sequence of
the allocations, you can determine which requirements will be fulfilled first (Selection Set). In addition, you can subsequently select individual allocation results
and change them once more in a collective processing (Reorganization).
In the following example you can see one possibility of the temporal sequence of the individual steps in the sales order processing. The allocation run is
always triggered at night. The individual customer requirements of the day are collected and can then be processed together. This guarantees that an overall
examination of the requirement situation is carried out and the allocation is executed according to the selected strategy. On the next day you can filter certain
allocations and, if necessary, they can be automatically changed. You can also start an allocation run in the preview mode using a background job.

Integration
During this procedure data is processed in the background while you carry out other functions on the screen. The background processes are not visible for the
user. That means there is no dialog possibility. However, they have the same priority as online processes.
The background processing of allocation runs is carried out similarly to that of the R/3 Standard. To plan a background job, the system requires the name of
the program to be executed and a variant that contains the selected program parameters for the requested run. You cannot plan allocation runs as background
jobs directly. You can create a variant for the program, but the selection conditions for the requirements must always be entered manually. Otherwise the
system would not know which requirements should be selected. Using the selection set the allocation runs are integrated in the background processing. Here
you can store the rules for the requirements selection in a selection variant, which is automatically called when starting the program. If you want to change or
reexplode certain allocations, you must do that in the online mode with the aid of the ARun Optimizer. For this you need to use the Reorganization in the
background processing.
As the processing of a large data quantity by the allocation run can significantly affect the system performance, you should always choose job class A. This
guarantees that the planning of an allocation run is considered with the highest priority by the system.

Prerequisites
The name of the program to be executed (with a related variant that contains the corresponding parameters) is required to implement the background
processing. The programs Selection Set (/AFS/ARUN_BATCH) and Reorganization (/AFS/ARUN_MANAGEMENTTOOL_BATCH) are available for the
execution of the allocation run. That means that you must create the corresponding variants before the job can be started.
In addition, you must completely maintain the parameters of the allocation run type or ARun Optimizer type.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 43 of 49

Features
You can trigger the background processing for each mode of the allocation run. You can plan a job via the selection set in the normal, simulation, and preview
modes. The functions of the ARun Optimizer can be executed in the background and can be used exclusively via the function Reorganization .

Activities
Implement the required background processing with the SAP job management. To do this you can use the programs Selection Set and Reorganization. Define
the program parameters in the related variant.

!--a11y-->

1.7.1 Selection Sets


Use
This function is required to carry out the allocation run in the background. You can separately maintain the selection parameters of the individual allocation
runs and assign them to the selection sets. You can save every record as a variant of the program. Thus the conditions required to plan a background job are
met.

Features
In a broader sense, a selection set consists of several allocation runs that are controlled by the same allocation type. Each of these individual allocation runs
has its own selection screen. The corresponding selection parameters are stored there. That means that it is possible to sequentially process several
possibly even differently configured allocations within a selection set.
When using selection sets, you can start processing in different modes: normal, simulation, or preview.
The scope of the release check can be redetermined before each program start. You can completely switch off the check, determine that the release check
should be carried out according to the checking rule that is stored in the allocation type, or determine that all checking rules should be taken into account
(including the customer-specific rule that is controlled by a release strategy).
You can determine whether the result screen of the executed allocation runs should be displayed. However, this is only useful for the online execution. If you
implement a selection set for background processing, the result display must be deactivated.
You can also implement version control for selections sets. In Customizing for ARun basic settings, choose Log Selection Set . Then the system
automatically creates a new version whenever you make a change to a selection set. This allows you to analyze the data used by allocation runs. This is
useful for troubleshooting. For example, if you are missing data in the current allocation run due to changes in the selection set and want to compare it to
previous runs.

You should only use version management in productive operation when necessary, since this does add to the system load during allocation
runs.

!--a11y-->

1.7.1.1 Deletion of Obsolete Selection Sets


Use
You can delete old selection sets that are no longer needed. It is recommended that you run the deletion program periodically to remove unneeded sets from
your database to free up storage space.

Activities
The deletion process involves two steps:
1. Setting a deletion flag for the sets
2. Running the transaction Reorganize Selection Sets (/AFS/SSET_REORG) to remove all sets that have deletion flags
Any amount of time can pass between steps 1 and 2. During this time you can set or remove deletion flags from sets as often as needed. Once you use the
Reorganize Selection Sets transaction to delete a set, though, you can no longer undo the deletion.
To mark a selection set for deletion, use the Change Selection Set transaction and check the deletion flag. This prevents the selection set from being used in
allocation runs. If you attempt to perform an allocation run that includes a flagged selection set, the system generates an error message.
When using the /AFS/SSET_REORG program, you can display a list showing:
All selection sets
Only those sets that have deletion flags
Selection sets with versions

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 44 of 49

You can also restrict which selection sets are to be deleted by choosing:
All selection sets
Only those selection sets created or changed by a specific user
Only selection sets created or changed on a specific date
You can select one or more sets from the list and then set the deletion flag for all of them at once, or remove the deletion flag from the sets.
In the same transaction, you can delete one selection set at a time. (For safety reasons, it is not possible to delete several selection sets with one button
click.) The system then checks to see if the selection set is still used in an allocation log or a parallel ARun batch job definition. If so, the system prompts you
to remove the selection set from those programs before you can proceed with deletion. If the selection set is not used anywhere, the system will display a
message confirming that the set will be deleted.
!--a11y-->

1.7.2 Reorganization
Use
The reorganization is an enhancement of the ARun Optimizer. It is the automated variant of the ARun Optimizer. With the reorganization you can plan the
function of the ARun Optimizer as a background job. This way you can combine larger volumes of data and process them outside the business hours. For
example, you can plan a job for the weekend in which different allocations of the previous week are to be selected and changed. The reorganization can also
be used online. By starting a single program you can easily process complete allocation runs whose results should be changed.

Integration
You need the ARun Optimizer type for the reorganization as well.
The selection variants are determined differently in the reorganization than in the ARun Optimizer. The variant for the reorganization is already permanently
assigned, whereas the variant for the ARun Optimizer has to be reselected for each run. You can use the variant that is entered as default value in the ARun
Optimizer type.
Like in the Multiple Allocation Selection Set you also need a predefined selection variant for the background processing, so that the required selection
parameters can be read by the System. As you must manually enter the selection parameters, when using the ARun Optimizer, a background processing
would not be possible.

Prerequisites
You must assign a selection variant as default value to the ARun Optimizer type, in which the required selection parameters are maintained. This ensures that
the required allocation is automatically selected by the system.
We recommend that you create a separate ARun Optimizer type for each background processing of the program. You can do this by copying a user-defined
reorganization type. You must then assign the selection variant as default value to the ARun Optimizer type, with the corresponding parameters.

!--a11y-->

1.8 Special Order Types


Use
For certain business transactions it is necessary to make special ARun settings. For AFS materials it is mandatory to carry out an allocation run before the
delivery creation.
1. Rush Order/Cash Sales
For rush orders you do not need an allocation, because the goods leave your own warehouse on the same day at the latest. It is assumed that only those
goods are available for sales that actually exist in the warehouse. The stock situation remains clear. You can tell the customer directly whether the ordered
goods are available in the requested quantity. So that a delivery is created when saving a sales order, the allocation run must be triggered, just like in the
standard ERP. For this it is necessary to store an allocation type for each sales area in AFS Customizing for the order types SO (rush order) and BV (cash
sales). That means that the allocation is automatically carried out for these order types after you have saved the document.
2. Consignment Processing
The consignment processing is subdivided in the following business procedures:
Consignment fill-up
Consignment issue
Consignment pick-up
Consignment returns

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 45 of 49

The consignment fill-up is the filling of the consignment stores of our customer. The goods must be posted from the unrestricted-use stock to the
consignment stock of the customer. As the goods are withdrawn from the unrestricted-use stock, the settings of the allocation run for this business transaction
are identical to the settings of a standard order. When the goods issue is posted, the materials are transferred to the consignment stock (special stock). There
are no special settings required for this.
The consignment issue is the withdrawal of goods by the customer from the consignment stock. For the system, this withdrawal means a stock reduction of
the special stock. Therefore the allocation run must access the special stock instead of the unrestricted-use stock during the stock selection. You must
choose a stock selection that selects the special stock MSKU with the stock segment KULAB. As there is no delivery of goods, the delivery can be
immediately carried out when the sales order is saved (sales order type KE). To do so, you must directly assign an allocation type to the order type KE, as
described in the section Rush Order / Cash Sales.
If the goods from the consignment stock of the customer are returned to the normal stock of our plant, it is called a consignment pick-up. For the system the
returned quantity must be posted from the special stock to the unrestricted-use stock. Make the settings for the allocation run as you would make them for the
consignment issue. You need a stock selection that accesses stock type MSKU and segment KULAB in this case as well.
Both consignment issues and consignment pick-ups must not exceed the quantity in the special stock. The maximum that you can withdraw or return is
the quantity that has been posted to the consignment stock. AFS does not support negative stock.
If your customer takes back goods into the consignment stock that were previously withdrawn, this procedure is called consignment returns. For this
process you do not need an allocation run. For more information see Returns Processing.
3. Third-Party Business Transaction
During a third-party business transaction there is no goods issue from the warehouse. The goods are sent directly from the vendor to the customer. That
means that you do not need to map any goods movements from the warehouse to the customer. You therefore do not need to carry out an allocation run for
this order type.
4. Make-to-Order Production/Purchase-to-Order Procurement
If you produce or order materials specially for one of your customers, these materials should not participate in a general allocation run. You must make sure
that exactly these goods are delivered to that particular customer. Therefore, the corresponding quantities are not posted to the unrestricted-use stock, but to
the customer special stock. It is therefore necessary to implement the stock selection to the customer special stock MSKA with the segment KALAB.
AFS does not support an allocation logic according to equal distribution for sales order stock.
5. Returns Processing
Although the returns processing is a sales document type from which a (return) delivery is created, an allocation run is not required. Returns are the only sales
order type for which you do not need an ARun. If a material is returned you must not decide which customer the goods should be assigned to, but rather the
goods must be posted to your returns stock. An allocation run is therefore not required. To ensure that an allocation run is not carried out when using the sales
order type RE, you must select the sales document category H in the sales document type.
6. Stock Transport Order
If you want to use the stock transport order with an SD delivery, you must store an allocation type for each purchasing document type. This ensures that the
allocation run is started in the background when later processing the delivery list. The allocation type is stored dependent on the purchasing document type
and the supplying plant.

!--a11y-->

1.9 Availability Check and Allocation Run


Availability Check Logic Versus Allocation Run Logic
The availability check in the AFS system checks at schedule line (SKU) level during the order entry if sufficient stock is available to fulfill the requirement on
the requested delivery date. If the result is negative, it checks when a sufficient quantity of stock will once again be available and confirms this date as the
new delivery date for the schedule line.
The availability check proceeds on the time line exclusively according to FIFO logic. The quantity available for a requirement is calculated from the warehouse
stock and the planned incoming stock on the one hand, as well as from all the planned outgoing stock (posted sales orders, reservations, blocked stock, and
so on) on the other hand.
The stock / requirements side is rechecked in the allocation run. While the requirements are assigned during the availability check on the time line to stock or
incoming stock, the requirements will be sorted during the allocation run depending on your individual settings. Possible criteria here could be the customer
number, delivery priority, document category, and so on. On the stock side, only stock that is customized in stock selection rule and falls within the ranges
provided in the allocation rule for the ARun type will be considered.
This means that the assignment of stock to requirements during the allocation can be based on a logic, which deviates from the availability check logic.
Capacity of Rescheduling
By implementing rescheduling you have the possibility of adjusting delivery dates of schedule lines that cannot be kept or are not optimal to the current stock /
requirements situation.

!--a11y-->

1.10 Check Tools for ARun


The following check tools are available for ARun:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 46 of 49

ARun Customizing Check Tool


In Customizing for the ARun type you can use the ARun Customizing check tool to check the configuration of existing ARun types for missing or
dangerous settings. This function is also available when you create a new ARun type.
You can also call the program for this function (/AFS/J_3AANL6) using the ABAP Editor.
ARun Delivery Check Tool
With the ARun delivery check tool you determine why a sales order could not be delivered. After making the order selection, you can activate different
checks or even combinations of checks.
!--a11y-->

1.10.1 ARun Customizing Check Report


Definition
This report shows Customizing entries for an ARun Type and optionally performs a consistency check on those entries. It is intended to assist consultants
and customers with ARun Customizing.

Use
Use this report to check whether you have made Customizing settings for ARun properly. It simulates an ARun and shows you what the results would have
been had the ARun been actually executed. The report:
Displays all Customizing parameters for a given ARun type in a tree structure. The customizing parameters, such as selection, grouping, and sorting, are
displayed as nodes, with the check results displayed as subnodes beneath each parameter.
Checks certain Customizing parameters, such as sorting, release, allocation, and so on. For each setting, the report displays a traffic signal lights
indicating whether it passed the check successfully (green light), or results in an error (red light) or warning (yellow light).
If one subnode indicates an error (red), the parent node has the same signal (red). If there is more than one subnode, the parent node inherits the most
severe signal. For example, if a parent node has two subnodes - one yellow and one red - the parent node will be red. Likewise, if one node is yellow and
one is green, the parent node will be yellow.
Allows you to double click on a node and jump right to the pertinent Customizing screen (in display mode).
Allows you to display ARun control data.

Structure
The report carries out the following checks:
Area:

Check for:

If the check finds that:

Result

Selection

Requirement rule

Order blocking is not set to exclusive

Error

Stock rule

Stock blocking is not set to exclusive

Error

Filter

Check rule

Extended credit check is set to ON

Warning

Grouping

Grouping rule

A grouping rule exists for the ARun type

Warning

but the Group Release Parameter is set


to zero
Sorting

Allocation

Schedule line header

A schedule line field has a higher priority Warning


than the header field

Group number

The requirements are grouped but the


Warning
group number (generated by the system,
GROUC/ GROUI) is not one of the sorting
fields with the highest priority

Preparation module

The sorting rule includes one or more

Warning

schedule line fields and the preparation


module is
J_3AR_ALLOCATION_PREPARE_1

Release

Log

Preparation module

The sorting rule does not include any


schedule line fields and the preparation
module is
J_3AR_ALLOCATION_PREPARE_2

Warning

Category check

The category check in the assignment is


set to 2 or blank

Warning

Grouping

There is no grouping rule but the release Warning


parameter for the grouping is greater
than zero

Determination rule

The usage is F but and no determination Warning


rule entries exist

Log file

The log file is not set (is blank)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Warning

Page 47 of 49

!--a11y-->

1.10.2 ARun Delivery Check Report


Definition
The delivery check report is a troubleshooting tool used to find out why a sales order has not yet been delivered. It checks for potential problems preventing a
sales order from being allocated and delivered, focusing primarily on the relevant master data (customer, material), the sales order itself, the most recent
ARun, and the delivery creation program.
All problems detected by the report are shown on a results list.

Use
The report shows a list of warnings or errors that would have occurred during an allocation run. Typical problems might be a customer master record that is
blocked for delivery, incorrect order type on the selection screen, or incorrect Customizing settings. By drilling down on an error message, you can see more
details about the cause of the error so that you can correct it.
The report carries out the following checks. It uses traffic lights to indicate whether the sales order encounters an error (red light), warning (yellow light), or
passes the test successfully (green light).
Check for

Result

Sales order already delivered

Warning

Customer has a delivery block for a given sales area

Error

Material is not an AFS material and/or AFS flags in the material master are not set
correctly

Error

Incomplete data for the delivery document

Error

Schedule has a delivery block

Error

Schedule line not relevant for delivery

Error

Schedule line does not contain a requirement type

Error

Schedule line has a rejection code

Error

Schedule line already delivered

Warning

Multiple MRP statuses for a item, delivery group, or schedule line group

Error

Some of the checks are optional. The default setting, though, is that all checks are executed. To avoid missing a potential problem, it is
recommended that you leave these settings as they are and that you run this report with all checks selected.
However do not use report with large volumes of data. To avoid long runtimes, be sure to choose selection criteria as restrictive and efficient as possible.

Structure
The report overview contains header information indicating the total number or sales orders processed and overall success of the run. For example, it might
indicate that out of 100 sales orders, 12 had customer delivery blocks, 5 had problems with the material master records and 1 had mixed MRP statuses,
and so on.
The first detail level of the report shows the following:
Flag

Meaning

Customer check

Sales document contains a customer-related problem (for example, delivery block)

Material check

Sales document contains a material-related problem (for example, AFS flags not
set)

ARun requirement selection

Indicates that the sales document was not selected by ARun

ARun filter

Sales document has been filtered by ARun

ARun release

Sales document failed the release check

ARun allocation

Sales document failed the allocation

Mixed MRP

Sales document passed the allocation but has multiple MRP statuses

Delivery exception

Sales document delivery process failed

Reserved stock

Stock for the schedule line has already been reserved for another sales document

The second detail level of the report shows the following:


Sales document number
Item line
Schedule line
Plant
Customer number

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 48 of 49

Material number
Incomplete fields (if applicable)
Description of the problem

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 49 of 49

Vous aimerez peut-être aussi