AID_OTC_ Allocation Process

Application Information Document –

Converse Allocation Process

1
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

Revision History
Revision Revision Date Summary of Changes Updated By

1.0 04/08/2015 Initial Draft Sunil Singh

Distribution List
Who Organization Action/Information Comment

OM Team Infosys Limited For First Review

Document Review Log

Revision Department/Function Reviewer Name(s)

2
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

1. Business Overview...............................................................................................................................4
2. Process Flow........................................................................................................................................5
3. Customization....................................................................................................................................16
4. Programs & Tables.............................................................................................................................16
5. Localization........................................................................................................................................17
5.1 Business Overview...........................................................................................................................17
5.2 Process Flow....................................................................................................................................17
5.3 Customization..................................................................................................................................17
5.4 Programs & Tables...........................................................................................................................17
6. Batch Job and Schedule.....................................................................................................................17
7. Known Issues and Suggestions..........................................................................................................17
8. Escalation Procedure.........................................................................................................................18
9. References.........................................................................................................................................18
10. Contacts.........................................................................................................................................18
11. FAQs..............................................................................................................................................18

3
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

1. Business Overview

Special situations in the apparel and footwear industry require an optimization of the assignment of
existing stock to open requirements. If the ordered quantities (Requirements) are larger than the actual
on hand available stock, the allocation run can be used to reach the best customer satisfaction under
the given circumstances. The ARUN Optimizer can be used to check and manually correct the results of
the allocation run if necessary.

An allocation run has to be carried out before delivery creation of any materials. The allocation run is
mandatory and cannot be switched off, except in the case of Direct Ship and PTO or MTO processes
where there is a direct link between the sales order and factory PO. The allocation type forms a
framework and contains all allocation rules and checks that have been defined for a specific business
process.

“Allocation is different than ATP, as ATP only confirms the order on the FIFO basis while allocation
process physically allocates the stock to the order and important customers get high preferences during
allocation. The allocation process comes after the ATP.”

Allocation is matching of demands with supply. Source of supply are stock in hand which is also called as
“C” stock, PO stock which is also called as “B” stock, ASN stock (In Transit) which is also called as “L”
stock. Demand comprises of sales orders, contracts and call offs.

Allocation happens in three different ways

 Automatic batch allocation which is known as ARUN

 Manual allocation.
 Immediate Allocations for Immediate orders

MRP Status:

 MRP status "T": Stock is temporarily assigned to a requirement. A temporary assignment occurs
when a sales order is created and there is supply to satisfy the demand.
 MRP status "F": The assignment of stock to a requirement is Fixed and the requirement can
therefore be released to pick. A fixed assignment occurs, for example, after executing an
allocation run if batch stock could be allocated to a requirement in the entire amount based
upon the allocation release rules.
 MRP status "R": The assignment of stock to a requirement is reserved only and the requirement
cannot be released to pick (Optimizer can be used to manually force allocate). A reserved
assignment occurs, for example, after executing an allocation run in which there was insufficient
stock to fill the order to the required release fill rate or when contracts have been allocated.

4
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
 MRP status “D”: The Delivery creation in SAP has occurred and the pick ticket has dropped to
WMS. Once the Post Goods Issue posts on the delivery the stock is no longer available and has
no MRP status.

2. Process Flow

5
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

The purpose of this document is to define the Allocation Process for the businesses on SAP. It includes,
at a high level, all ARUN process functions including the following:
 Requirements Selection
 Stock Selection
 Requirements Checking
 Requirements Grouping
 Sort/Priority
 Release Rules
 Allocation Execution
 Optimizer (ability to manually force allocate)

Order selection /Stock selection: In Converse only Batch stock C and Special stock E type stocks are
selected for ARUN. In this step of the allocation run, one must determine which customer orders should
participate in the next allocation run as well as which stock the allocation run should access. Converse
needs the ability to run separate allocation jobs and for unique rules by region (Sales Organization). SAP
provides the flexibility to setup multiple Allocation Types with its own unique rules and/or run Allocation
by specific Sales Organizations, Plants or whatever selection criteria is decided upon during the design
phase. Standard functionality will be used to satisfy the requirement.

It also specifies whether the selected requirements records are locked for other users or processes
during the allocation run. SAP recommends that the indicator exclusive lock should be set. This is
especially important if it is desired to execute several allocation runs at the same time in the
background. Only the exclusive lock ensures that two allocation runs that are processing in parallel do

6
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
not select the same requirement record. Otherwise, the same requirements record might be allocated
twice. Converse will be using SAP recommended settings.

The physically existing stock and special stock are considered during allocation. The Converse
requirement is to have the nightly allocation job only consider Finished Goods.

Converse will only consider unrestricted batch stock during the Allocation Run. There is a requirement to
be able to view inventory that are not relevant for allocation. This can be done by running the Stock
Requirements List (/AFS/MD04) or Stock Overview (MMBE), which are standard reports.

 including PTO and MTO

 Including free Batch stock and MTO/PTO stocks but no future stocks like PO, PR and Production
orders.
 Direct access and separate access variant are created for each region.
 Extensions “0001” is allowed to consider whole orders even RDD for some items are out of
selections options.

Order checking: Order based on pre-configured criteria like with certain credit block, Delivery block,
incomplete orders status etc. are removed from selection. This is done based on the configuration done
under the node “Requirement Filter -> Check Rule”.

Requirements Selection step to filter out those which could have the following issues:

 Delivery blocked orders : Orders with delivery blocks should be filtered out except for specific
blocks that should allow for allocation, which will be handled in the Selection Set variant
 Validation of season: No checked on season.
 Maximum deliveries for the customer: No checked.
 US and Canada are not using the Cancel date in requirement filter but other regions are
considering cancel date check within 5 days.
 Orders will also be allocated if orders are credit hold and logs file show the entry if orders are
allocated for credit block but delivery won’t create for credit hold.
 Max no delivery is not considered in allocation requirement filter check and orders can be
allocated even the orders reached to maximum del but delivery won’t be created and a separate
program will check the all open orders which reached to Max Del and reject the all open units.

Order Grouping:

Some customers are set up for orders grouping strategy. Orders are grouped based on the pre-defined
the fields. In Converse, Orders are grouped based on Order type, Sold to , Purchase order no and RDD.

Allocation will allocate the together all grouped orders if release rule are matched otherwise they all
need to wait until stock are not fulfilled.

ZAG1 group strategy should be assigned to customer master in case of allocation grouping.

7
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
Converse used permanent grouping strategy.

Order sorting and Allocation logic: Selected and filtered orders are sorted / prioritized. Order sorting is
based on done the following criteria Delivery Priority (LPRIO), Order type(AUART), Confirmed date
(EDATU), and Order Number (AUFNR). This is controlled through MASS SETS. Sorting is the tool for
optimal distribution of insufficient quantity of stock among the existing orders according to specific
criteria. For example, customers with high priority are given preference and are supplied with the goods
first.

 US and Canada have two separate allocations based on priority. One is for 1-3 and another is for
4-7.
 US and Canada do not consider order reason for requirement priority but other regions are
using it and giving high preference to future order rather than rush order or immediate orders.
 Allocation rule is checked on category. So that system won’t be allowed to allocate orders with
any other stock category. It should match requirement category with stock category.
 FPFO (first priority first out) logic states the customer orders will be allocated based on Account
and Door priority as set up in Master data files.
 FIFO (first in first out) logic states the customer orders received first will be the orders to
allocate first.
 Equal distribution. Orders equally distributed if they are belongs to same Allocation group.

Stock sorting: Once the orders are sorted, stocks to be assigned will also be sorted

Stock assignment: In this step system would assign stock against every selected individual sales order.

Release: Though the stocks are allocated, if the allocated stock is not a “C” type stock or the release rule
is not met then system will not move the status of the sales order to “F” instead it will have “R”
(Reserved) status. Only if the stock allocated is of type is “C” type and release rules are met then the
status is set as “F” fixed. This means the allocation for that particular sales order is released and ready
for shipping/ delivery creation. Each allocation type is set with default release percentage. Release rule

8
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
exit at delivery line item level and delivery group level.

In this step of the allocation run, 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.

Converse needs the ability to set different release percentages by Sold-to, Ship-to or at a sales order
level. This is standard functionality and will require that multiple Release Rules be configured in the IMG
by the project team.

Release rule ZSAC Ship & Cancel (Fill & Kill) orders which could not be allocated 100% will have the
remaining open units cancelled. This applies to only QRP (quick response program/Replenishment)
orders where the account cannot accept more than one shipment against their purchase order. This is
referred to as the two-step rejection process in AFS which means that ARun will flag the order for
rejection and then a subsequent job setup with the Mass Document Change tool (/AFS/MDC) will carry
out the rejection on the sales order.

All above set of factors are included in ARUN type. ARUN TYPE will control the behavior of allocation.
ARUN TYPE contains the entire basic configurations done for allocation purpose. ARUN TYPE
configuration is as shown below

9
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

10
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

In ARUN type of allocation the stock is allocated to the sales orders and contracts using standard
business rules in batches. Most of the orders are allocated through Batch ARUN. Rules/priorities for
allocation using ARUN are controlled through MAS Sets (Mas allocation sets). Each ARUN is a group of
Mas Sets which runs in a given sequence. Example: US01 Plant US SET 1 PRIORITY 1-3 RDD -180 +45
DAYS

11
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

In the above screenshot it is demonstrated that for one MAS Set only one Access rule would be active
and that is indicated by Number 1.

Details of the Access rules are as shown below

12
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

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.

Batch allocation:

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. Using the Selection Set, the allocation
runs are integrated in the background processing.

13
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
Selection Set : 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 .

Normal AFS Batch Process ( /AFS/ARUN_BATCH). Selection set used in this program to execute in
background.

Parallel Batch: “/afs/arun_parallel” is the program which is used in ARUN batch job scheduling. MAS
sets are created and handed over to batch team, and then they set up the sequence and time of the
ARUN as per the business requirement.

ZSD_ARUN_VARIANT_CHG is used to change RDD and other some field for selections sets as standard
doesn’t allow variable RDD in selection sets.

Manual Allocation:

The majority of orders are intended to go through the nightly batch allocation process. However,
there are business reasons that we have to manually allocate some materials. Orders may go
through manual allocation for the following reasons:

 Order is failing release rule check and customer will take whatever they can ship on the same day.

 Product has just been received and an order for that product needs to be expedited.

 Management approval to assign product out of allocation priority sequence inventory adjustments.

J3AT is the T code for running the manual allocation.

14
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

15
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
The above methods are used when the customer says they will take now whatever they can get. Any
existing material in an R status would change to F, and any material in an open status would stay open
until more material arrived.

Immediate allocation:

ZIMD and ZDIG are two types of orders which allocated immediately. Here an ARUN Type is assigned to
an Sales Order Type via configuration setting in Arun “Cross Applications -> SD Handling -> Assign Rule to
Order Type.” This is use for immediate order types.

ARUN Optimizer/De-allocation:

This online tool is used for viewing and managing post-ARun allocations. It helps to quickly locate areas
that are likely to fail release by displaying real time allocation release percentages and stock allocation
details at different levels.

Using the ARun Optimizer, manually changing or resetting the results of the allocation run can be carried
out. This helps the business to react to a changed stock and requirements situation any time after the
allocation run. With the ARun Optimizer, individual assignments can be manually selected and changed
(force allocating)

The Converse requirement is to have the ability to de-allocate stock that are in a Reserved (R) or Fixed
(F) status, or to force allocate anything in a Reserved (R) to a Fixed (F) status. This is standard
functionality but de-allocation rules and Optimizer Types need to be configured in the IMG.

16
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

Important Points:

 No custom program has been developed for Allocations. A wrapper program is only developed
to set the change the job variant for selection sets. It allows us to change RDD dynamically for
ARUN.
 CSR manually changed to release rule ”ZAV” in sales orders in case of 100% release are not
matched and customer is ready to except whatever stock are available.
 As per Business requirement, we don’t consider Future receipts are the part of allocations.
 AFS inconsistency can be creased in case of future receipt are considering during allocations.
 Selecting all orders including PTO and MTO
 Selecting Batch and MTO/PTO stocks but no future stocks like PO, PR and Production orders.
 We are using Direct access and separate access variant are created for each regions.
 Extensions “0001” is allowed to consider whole orders even RDD for some items are out of
window selections.

17
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process
 Order can be allocated for incompletions log for those fields which allow to create a delivery.
Examples: Orders are incomplete due to customer expected price but we are allowing to
allocate and delivery but Invoice is hold until the price are not corrected.
 Allocation grouping for some customers are based on order type, PO no, Customer no and RDD.
System allocate together all orders if orders are grouped.
 Permanent grouping give the better performance and grouping happened when order are
created and allocation used grouping table to allocate the orders while temporary grouping give
lesser performance and all grouping logic is actually carried out during allocation run but results
should be same.
 Reallocation will consider the both R-reserved and F-fixed status during next allocation rule.
 BOM release rule are required for component materials.
 Release rule ZAV – Anything available.
 ZSAC rule – For QRP orders. Fix and KILL. Any open quantity will be rejected with rejection code
XX.
 Some of the Account Reps. can change the release rules in the Sales Orders before the Arun. If
customer asks whatever available to deliver, then Account Rep can change the release rules in
Sales Order accordingly.
 Release rules of QRP can also be changed, but it’s not very frequent.
 ARUN looks at only physical Stock. It will not consider future receipts.
 Z5 & Z6 Delivery blocks will not go thorough allocation.
 Some Incompletion Log will allow & not allow allocation to happen. E.g. – Customer expected
price will allow allocation to happen.
 Orders on Credit hold will be allocated.
 EMEA, Taiwan will not allow allocation if the cancel date is in past.
 Permanent Grouping at converse.
 Future Orders has priority upon QRP Orders.
 No substitutions for ATP & ARUN.
 No user Exits Implemented.
 Arun Variant change Program for selection Set
 ZSDR_ARUN_Variant_CNG – T code
 FD.EXT.OTC.520
 Extension functionality – Minimize Charge backs for Converse

Customization

Link:

\\converse\DavWWWRoot\sites\sap\otc\Shared Documents\CR-OTC-18-Allocation Run (ARUN).docx

18
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

3. Programs & Tables

ZSD_ARUN_VARIANT_CHG: It is designed for change RDD dynamically for Night Batch ARUN.

J3AT: At Once Arun. Used for exceptions under management direction. I.E. order expedite, launch
product.

J4AS: Is the transaction for creating the MAS SETs.

J4AR: Change Mas Sets. Sequence depends on business/geography.

J3AS: Is the transaction for all ARUN related configuration.

MCHB: Stock table: “C” stock

MSKU: Consignment stock table

J_3ABDBS: Allocation table by requirement

J_3ABSSI: AFS Purchasing table: the “Supply Table”: “L” ASN and “B” PO

J_3ABDSI: AFS Requirement table: the “Demand Table”

ARUN LOG FILES

/AFS/ARUN_PROT: Main Arun Log File

/AFS/ARUN_PROI: Exceptions in Arun processing

J_4ALOGTAB: New log file from SAP/AFS. Large amount of data – utilized to identify root causes of
table imbalances. Currently, this is not activated for Converse.

4. Localization
5.1 Business Overview

5.2 Process Flow

5.3 Customization

5.4 Programs & Tables

19
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

5. Batch Job and Schedule

ARUNs by Region PDT IST CST

Asia/Pacific ARUN 9:00am 9:30pm 12:00 PM

EMEA ARUN 02:00pm 02:30am 05:00 pm

North Americas ARUN 8:00pm 8:30am 11:00 pm

6. Known Issues and Suggestions

S. No. Description Root Cause Action Taken/Needed Time Frequency

Spent

7. Escalation Procedure
<Include the details of Escalation procedure>

S. No. Escalation Contact Role Mail Contact Threshold

Period

20
CLIENT PROPRIETARY AND CONFIDENTIAL
 AID_OTC_ Allocation Process

8. References
\\converse\DavWWWRoot\sites\sap\otc\Shared Documents\BPD.OTC.18.Allocation Run (ARUN).docx
\\converse\DavWWWRoot\sites\sap\otc\Shared Documents\SAP OTC-18 Allocation Run (ARUN) Current State BPD.docx
\\converse\DavWWWRoot\sites\sap\otc\Shared Documents\CR-OTC-18-Allocation Run (ARUN).docx
\\converse\DavWWWRoot\sites\sap\otc\Shared Documents\FD.EXT.OTC.520 – Allocation Run Custom Work.docm

9. Contacts
Name of Business / System/support Mail Id
Person
Consulting / Department

10. FAQs

21
CLIENT PROPRIETARY AND CONFIDENTIAL