AFS Allocation Wholesale

Allocation Run
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_afs64/helpdata/en/72/702037b1f10709e10000009b38f839/frameset.htm
Created on April 30, 2015
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.
© 2015 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 Page 1 of 47
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
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.5 Stock and Requirements Sorting
1.1.6 Allocation
1.1.6.1 Allocation Rule
1.1.6.2 ARun Substitution
1.1.6.2.1 Customizing for 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 Changes during Goods Receipt
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
1.11 Allocation Run (ARun) Change Log
PUBLIC Page 2 of 47
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 Page 3 of 47
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.
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
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

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 company’s own and the external stock. However, with the company’s 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.
PUBLIC Page 4 of 47
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.
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.
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:
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 4
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
PUBLIC Page 5 of 47
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.
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.
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.
Requirements Check
Use
PUBLIC Page 6 of 47
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.
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
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.
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:
PUBLIC Page 7 of 47
· 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.
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.
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
PUBLIC Page 8 of 47
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

6. Individual Group Allocation Logic

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.
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
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.
PUBLIC Page 9 of 47
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 party’s view of the Customer Master Record
KUWEV Ship-to party’s 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 .
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
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 Key
VBAK KUNNR (customer number) 3
PUBLIC Page 10 of 47
KUAGV BLAND (location) 2 X
VBAP WERKS (plant) 1 X
KUWEV ORT01 (ship-to location) 4
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
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 mistakenly
affecting sales orders in another CSR’s 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 .
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
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.
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.
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 don’t 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).
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.
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 T shirts 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 T shirts in CSR stock. You allocate these 30 to your order, which brings the total up to 70 T shirts. You next check the Own
Assignments , where you see that you have already allocated 90 T shirts 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 T shirts. 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 T shirts 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 T shirts 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
T shirts, thus fulfilling the order.
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 1 50 Green 5.12.1999
20 1 10 Red 5.11.1999
20 2 20 Yellow 6.12.1999
In this case the result of the sorting is as follows:
Item Schedule Line Pieces Color Confirmed Delivery Date
20 1 10 Red 5.11.1999
10 1 50 Green 5.12.1999
20 2 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.
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:
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.
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
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
1 Confirmations – 25 –5
2 Production Orders – 10 –2
3 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.
1.1.6.2 ARun Substitution
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 (transactions VB11/VB12 in the standard SAP system) and select a material determination type.
3. In the Material Entered 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).
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.
Substitution with different allocation logic:
● FIFO: The main material is allocated in FIFO logic. When this is exhausted then the allocation continues with the substitute materials.
● Even Spread: The system spreads the original and substitute materials evenly across the group. The original and substitute material are considered together
for the spread.
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 temporary 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
You must have maintained Customizing for 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)
● Requirement category substitution is not supported.
● Plant substitution is not supported.
1.1.6.2.1 Customizing for Substitution
Purpose
To enable substitution, define the substitution logic in Customizing in the order listed below.
Process Flow
Creating Substitution Strategies

1. In Customizing, choose one of the following:
○ AFS Allocation Run ® ARun Detail ® Substitution ® Substitution Strategy (for, ARun)
○ Sales and Distribution ® Basic Functions ® Availability Check and Transfer of Requirements ® Availability Check ® AFS
Substitution ® Substitution Strategy (for, ATP)
2. Enter a unique identification (4 alphanumeric) for this new strategy, plus a free-form description.
3. Save the strategy.
This function is optional for ARun but mandatory for ATP.
Creating Rules
You can either use the existing substitution rules or create new ones. To create new rules:
○ AFS Allocation Run ® ARun Detail ® Substitution ® Substitution Rule (for, ARun)
Substitution ® Substitution Rule (for, ATP)
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.
Assigning Substitution Rules to Strategies

○ AFS Allocation Run ® ARun Detail ® Substitution ® Determination Table Maintenance (for,ARun)
Substitution ® Determination Table Maintenance (for, ATP)
2. Assign a substitution rule for each customer-specific substitution strategy you created. You can assign the same rule to different strategies.
Assigning Substitution Strategies to Customers

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.
3. Enter the substitution strategy you created above. Under ARun data, you can assign the substitution strategy for ARun substitution. Under Order Proposal ,
assign the substitution strategy for ATP substitution.
Activating the Substitution Logic

1. Do one of the following:
a. In Customizing, choose AFS Allocation Run ® ARun Optimizer ® ARun Optimizer Control ® ARun Type . Select the ARun type (allocation
type) you want to maintain
b. In Customizing, 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.
■ 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.
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,
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.
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 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).
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 Fixed The stock has a fixed reservation and is assigned to the

(ARun status) requirements. Only stock with this status is eligible for
subsequent delivery note creation.
R Reserved The stock is reserved and is assigned to the requirements.

(ARun status) 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.
B Blocked MRP has blocked the requirements. If the physical

(MRP status) 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.
A Unrestricted stock The stock is immediately available.

(MRP status)
T Temporary Stock assigned to requirements without guarantee, and is

(MRP status) 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 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)
Rejecting a schedule line in an allocated contract 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 Automatic deallocation of the contract item category is Warning message. The remaining quantity (after
contract active reduction) has status R.
Automatic deallocation of the contract item category is not Error message. Entire schedule line quantity retains status
active R.
Deleting a schedule line from an allocated contract 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.
Adding a quantity to an existing schedule line in an The contract type contains an ARun type The added quantity that is available in inventory has status
already reserved contract R (reserved).
The contract type does not contain an ARun type The added quantity that is available in inventory has status
T
Adding a new schedule line, material, or item to an The contract type contains an ARun type The added quantity that is available in inventory has status
already reserved contract R (reserved).
The contract type does not contain an ARun type The added quantity that is available in inventory has status
T
Creating a sales order with reference to an already The sales order type contains an ARun type The sales order has status F or R, depending on the
allocated contract release rule
The sales order type does not contain an ARun type Status R of the contract is transferred to the sales order
Creating a sales order with reference to a non-allocated The sales order type contains an ARun type The quantity may have status F, R, or T depending on
contract 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
Rejecting a schedule line with status R or F within a sales Automatic deallocation is active in the item category for the The quantity goes back to contract with status R.
order material ordered in the release
Automatic deallocation is not active in the item category for Error message. Rejection is not possible.
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
The sales order type does not contain an ARun type The schedule line receives status R.
Reducing the quantity of a schedule line in an allocated Automatic deallocation is not active in the item category for Error message. Reduction is not possible.
sales order the material ordered in the sales order
Automatic deallocation is active in the item category for the The reduced quantity is returned to the contract with status
material ordered in the sales order, and the Restore R. The status of the sales order (R or F) remains
setting is active unchanged.
Automatic deallocation is active in the item category for the The reduced quantity is returned to unrestricted stock. The
material ordered in the sales order, but the Restore status of the sales order (R or F) remains unchanged.
setting is not active
Deleting a schedule line within an allocated sales order Automatic deallocation is not active in the item category for Error message. Deletion is not possible.
the material ordered in the sales order
Automatic deallocation is active in the item category for the The quantity of the deleted schedule line is returned to the
material ordered in the sales order, and the Restore contract with status R.
setting for the contract order type is active
Automatic deallocation is active in the item category for the The deleted quantity is returned to unrestricted stock. The
material ordered in the sales order, and the Restore status of the sales order (R or F) remains unchanged.
setting for the contract order type is not active
Adding a new item or schedule line to an already allocated The sales order type contains an ARun type, and the After saving the sales order, the new item or schedule line
sales order added quantity is within the contract's open quantity receives status F or R, depending on Customizing
settings. The contract is updated.
The sales order type contains an ARun type, and the Depending on the Customizing settings for the order
added quantity is more than the contract's open quantity 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.
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 of Changing Sales Orders
· Consequences of Changing Purchase Orders
· Consequences of Changing Confirmations
· Consequences of 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”
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
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 Sort descending
J_3ASTAT 1
J_3ABSKZ 2
EDATU 3
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).
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:
J_3ASTAT 1
LPRIO 2 X
EDATU 3
By selecting Sort descending flag for the delivery priority (LPRIO), the system deallocates the least important orders first.
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:
LPRIO 1 X
EDATU 2
By selecting Sort descending flag for the delivery priority (LPRIO), the system deallocates the least important orders first.
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
1.1.6.6.5 Consequences of Changes during Goods Receipt
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 (today’s 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
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.
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:
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
S 1. Use the rule in the sales order

2. Use the global release check rule
F 1. Use the rule in customer master

X 1. Use the rule in the sales order

2. Use the rule in customer master
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 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 Schedule line Required quantity Available quantity
group
0815 TS01 10 001 S 10 5
002 M 1 10 3
003 L 1 10 5
004 XL 10 10
TS02 20 001 S 10 5
002 M 10 1
003 L 1 10 10
004 XL 1 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.
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 Wednesday’s 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.
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 today’s 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.
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 .
1.3 Parallel ARun Execution
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 Yes

(Splits up the selected sales order requirements and (Processes all sales order requirements for one material
assigns them to the various tasks) assigned to it by the main program)
Filters out sales orders that fail to meet ARun type check -- Yes
rule
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.
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.
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.
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 Final Action Release check MRP Status ARun Event ARun Status
Release Rule Rule passed?
1 VIP 100% E at order yes M Yes, R Blank XMKR

header level K No, R E EMKR
2 Normal 80% E at order Standard release R Yes, F Blank XRDF

header level rule of the D No, R E ERDR
allocation type
3 Special 90% E at order Yes A Yes, F Blank XAKF

header level K No, R E EAKR
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 (tomorrow’s) 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 Required quantity Available quantity Pass/fail release check
at schedule line level
T-shirt XL 1 10 10 Pass
2 10 3 Fail
T-shirt L 1 10 10 Pass
2 10 5 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) 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 ).
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.
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 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
1.6 ARun Optimizer
Use
You use this 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.
You can also use this function to view the error/exception messages that occurred while performing the operations until you have saved the changes.
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 have activated the business function AFS Allocation Run Optimizer (/AFS/ARUN) to view the error/exception messages.
● You must have maintained the necessary settings for ARun in Customizing by choosing AFS Allocation Run .
● You must have regenerated all the existing selection reports for Application Area – Assignments (1) and Requirements (4) .
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 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 re-distribution, 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 pre-define 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 indicated 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. Indicated/selected orders have a much higher probability of allocation
in an ARun, timed to run after goods receipt(s) just for these orders. However, this has no impact on physical inventory or ATP, MRP, and so on. ARun allocates
indicated/selected orders up to limits specified by the user.
The Optimizer also has the following feature:
Display of Exception/Error Messages
The messages are displayed only for the following cases:
● Failed delivery
● Release rule check messages
● Total reallocation messages
Activities
You must also do the following:
● To regenerate the existing selection report, in Customizing choose AFS Allocation Run ® ARun Optimizer ® ARun Optimizer Control ®
Selection Report Generation.
● To save messages to the database in Customizing choose AFS Allocation Run ® ARun Optimizer ® ARun Optimizer Control ® Configure ARun
Optimizer Type .
Select the field Incl. Exceptions under the Additional tab of the ARun Optimizer: General Parameters: Details Screen .
● To choose the messages that you want to save to the database and to remove/delete the unwanted messages as per the requirements, implement the
Business Add-In BAdI: Filtering Exception Messages (/AFS/ARUN_PROI_FILTR) in Customizing by choosing AFS Allocation Run ® ARun Optimizer
® BAdI: Filtering Exception Messages .
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.
Redistributing Allocated Quantities Within an Allocation Group
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 deallocate 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
1 12345 Large 10 7
2 12345 Large 10 7
3 12345 Large 10 7
4 12345 Large 10 6
5 12345 Large 10 6
If you redistribute using a FIFO strategy, the system reallocates the stock as follows
Order Material Size Requirement Allocated
1 12345 Large 10 10
2 12345 Large 10 10
3 12345 Large 10 10
4 12345 Large 10 3
5 12345 Large 10 0
In total reallocation, selected allocations are first deallocated and then fresh allocations take place. But, redistributing allocated quantities within an
allocation group does only allocation.
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.
Total reallocation does deallocation as well as allocation, while redistributing allocated quantities within an allocation group does only allocation.
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.
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
CSR’s orders. You can also give a user the authority for only one ARun Optimizer type.
Standard SAP ERP System Authority Checks (CSA-Independent)

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.
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 Optimizer’s 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 Optimizer’s 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 .
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).
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.
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.
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.
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
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.
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.
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
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.
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.
1.10 Check Tools for ARun

The following check tools are available for ARun:
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.
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 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
Allocation Preparation module The sorting rule includes one or more Warning
schedule line fields and the preparation
module is
J_3AR_ALLOCATION_PREPARE_1
Preparation module The sorting rule does not include any Warning
schedule line fields and the preparation
module is
J_3AR_ALLOCATION_PREPARE_2
Category check The category check in the assignment is set Warning

to 2 or blank
Release 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 Log file The log file is not set (is blank) Warning
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 Error
correctly
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
¡ Material number
¡ Incomplete fields (if applicable)
¡ Description of the problem
1.11 Allocation Run (ARun) Change Log
Use
You use this function to track changes made to allocation results of AFS sales orders and to store those changes.
Prerequisites
You must have done the following:
● Activated the business function AFS PDF-based Forms and Simplification (/AFS/FORM_SIMPLIFICATION) .
● Defined number range for log file, in Customizing by choosing AFS Allocation Run ® ARun General Settings ® Number Ranges ® Define Number
Range for Logfile .
● Activated ARun log for table J_3ABDBS , in Customizing by choosing AFS Allocation Run ® ARun General Settings ® Activate Log File for ARun and
SD Inconsistency (transaction /AFS/ACTIVATE_LOG).
Features
This function enables you to:
● Log the allocation and/or deallocation changes made to a sales order during sales order change, online ARun, Parallel ARun, Batch ARun and ARun
Optimizer.
● Refresh the old log entries for table J_3ABDBS by going to the SAP Easy Access menu and choosing Logistics ® Allocation Run ® Environment
® Log File Processing ® /AFS/REFRESH_LOG - Refresh Logging Tool (transaction /AFS/REFRESH_LOG).
Activities
You must do the following:
● Execute online ARun, ARun Optimizer, Batch ARun and Parallel ARun to allocate and/or deallocate sales orders or change already allocated sales orders.
● Analyze log file for table J_3ABDBS, by going to the SAP Easy Access menu and choosing Logistics ® Allocation Run Environment ® Log File
Processing ® /AFS/ANALYSE_LOG - Analyze Logging Tool (transaction /AFS/ANALYSE_LOG). You must then do the following:
○ Enter table name as J_3ABDBS and other selection criteria (for example, material, plant).
○ Choose the radio button Display ARun Log Entries and choose Execute . Relevant log entries are displayed in the form of ALV grid.
● Refresh log file for table J_3ABDBS in case log file grows very large by going to the SAP Easy Access menu and choosing Logistics ® Allocation Run
® Environment ® Log File Processing ® /AFS/REFRESH_LOG - Refresh Logging Tool (transaction /AFS/REFRESH_LOG ). You must then do the
following:
○ Enter table name as J_3ABDBS.
○ Choose the radio button Refresh only ARun Log Entries and choose Execute .
● Filter the log entries which must be saved to the database, by implementing BAdI : Filter Logs in Customizing by choosing AFS Allocation Run ®
ARun General Settings ® BAdI: Filter Logs .
You can use the same logging tool to detect data inconsistencies in sales document and stock tables. For more information, see SAP Note
1281463.

AFS Allocation Wholesale

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AFS Allocation Wholesale

Uploaded by

Copyright:

Available Formats

Allocation Run

PDF download from SAP Help Portal:

Created on April 30, 2015

1.1 Steps in the Allocation Run

Rule for the Requirements Selection

Rule for the Stock Selection

1.1.1.1 Access Rule

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

Dynamic Open to Delivery Date Adjustment

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 4

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)

Flagging Orders for Special Handling

1.1.3 Requirements Grouping

General Requirements Grouping

Customer-Specific Requirements Grouping

1.1.3.1 General Requirements Grouping

1.1.3.2 Customer-Specific Requirements Grouping

3. Grouping Rule and Grouping Criteria

4. External Group Numbers

5. Individual Group Release Rules

6. Individual Group Allocation Logic

7. Requirements Sorting by Allocation Groups

8. Renaming of External Group Numbers

1.1.4 Customer Service Areas (CSA)

KUAGV Sold-to party’s view of the Customer Master Record

KUWEV Ship-to party’s 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

1.1.4.1.1 Example: CSA Table

Table Name Field Name Sequence Key

VBAK KUNNR (customer number) 3

VBAP WERKS (plant) 1 X

KUWEV ORT01 (ship-to location) 4

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

Assigning Allocation Groups to 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.5 Stock and Requirements Sorting

Item Schedule Line Pieces Color Confirmed Delivery Date

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

Item Schedule Line Pieces Color Confirmed Delivery Date

1.1.6.1 Allocation Rule

· Cancel date = December 15

You enter the following here:

Priority Stock Type From To

1.1.6.2 ARun Substitution

1.1.6.2.1 Customizing for Substitution

Creating Substitution Strategies

This function is optional for ARun but mandatory for ATP.

Assigning Substitution Rules to Strategies