HELP SAP. Purchasing

Purchasing
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/ea/98c7536e8e2a4be10000000a174cb4/content.htm
Created on April 12, 2016
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing
subtopics.
© 2016 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC Page 1 of 99
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 Purchasing
1.1 Requirements Planning
1.1.1 Basic Principles
1.1.1.1 Requirements Planning: Supply Source Determination
1.1.1.2 Requirements Planning: Forecast
1.1.1.3 Requirements Planning: Forecast With Alternative Historical Data
1.1.1.3.1 Alternative Historical Data
1.1.1.3.2 Post Distribution Forecasting
1.1.1.4 Requirements Planning: Using Delivery Relationships
1.1.1.5 Requirements Planning: Quantity Allocation (Push)
1.1.1.6 Requirements Planning: Determination of Requirements (Pull)
1.1.2 Planning Workbench
1.1.2.1 Working with Worklists
1.1.2.2 Online Planning
1.1.2.2.1 Reference Scenario
1.1.2.2.2 Settings
1.1.2.2.3 Using Online Planning
1.1.2.2.4 Using User Exits to Adapt Online Planning
1.1.2.3 Order Cancelation
1.1.2.4 Internet Services
1.1.2.5 General Settings
1.1.3 Replenishment
1.1.3.1 Replenishment: Inventory Management Types
1.1.3.2 Replenishment: Examples for using Replenishment
1.1.3.3 Replenishment: Master Data
1.1.3.3.1 Replenishment: Article Master Data for Sites
1.1.3.3.2 Replenishment: Article Master Data for External Customers
1.1.3.3.3 Replenishment: Structured Articles
1.1.3.3.4 Replenishment: Logistical Variants
1.1.3.3.5 Replenishment: Requirement Groups
1.1.3.3.6 Replenishment: Example of Requirement Groups Usage
1.1.3.3.7 Replenishment: Site Master Data
1.1.3.3.8 Replenishment: Check Consistency of Replenishment Data
1.1.3.4 Replenishment: Forecasts
1.1.3.5 Replenishment Planning
1.1.3.5.1 Replenishment: Inclusion of Expected Receipts and Issues
1.1.3.5.2 Replenishment: Including Expected Receipts and Issues
1.1.3.5.3 Replenishment: Planning Using Dynamic Target Stock
1.1.3.5.4 Replenishment: Using a Reorder Point
1.1.3.5.5 Planning Replenishments
1.1.3.6 Replenishment Monitor
1.1.4 Multi-Step Replenishment
1.1.4.1 Multi-Step Replenishment: Inventory Management Types
1.1.4.2 Multi-Step Replenishment: Scenarios for Multi Step Replenishment
1.1.4.3 Multi-Step Replenishment: Master Data
1.1.4.3.1 Multi-Step Replenishment: Article Master Data for Sites
1.1.4.3.2 Multi-Step Replenishment: Structured Articles
1.1.4.3.3 Multi-Step Replenishment: Logistical Variants
1.1.4.3.4 Multi-Step Replenishment: Requirement Groups
1.1.4.3.5 Multi-Step Replenishment: Example of Use of Requirement Groups
1.1.4.3.6 Multi-Step Replenishment: Site Master Data
1.1.4.4 Multi-Step Replenishment: Sales Forecast
1.1.4.5 Multi-Step Replenishment: Replenishment Planning
1.1.4.5.1 Inclusion of Expected Receipts and Issues
1.1.4.5.3 Planning Using Dynamic Target Stock
1.1.4.5.4 Using a Reorder Point
1.1.4.6 Using the Replenishment Monitor in Multi-Step Replenishment
1.1.5 Requirements Planning: Special Article Categories
PUBLIC Page 2 of 99
1.1.5.1 Requirements Planning: Structured Articles
1.1.5.1.1 Requirements Planning: Calculation of the Quantity Required of H
1.1.5.2 Requirements Planning: Logistical Variants
1.2 Ordering
1.2.1 Supply Source Determination
1.2.1.1 Supply Source Determination: Evaluating Quota Arra
1.2.1.2 Supply Source Determination: Evaluating the Source List
1.2.1.3 Supply Source Determination: Finding External or I
1.2.1.4 Supply Source Determination: Requests for Quotatio
1.2.2 Order Optimizing
1.2.2.1 Quantity Optimizing
1.2.2.1.1 Master Data and Customizing for Quantity Optimizing
1.2.2.1.2 Static Rounding Profiles
1.2.2.1.3 Quantity Addition and Subtraction
1.2.2.1.4 Dynamic Rounding Profile
1.2.2.1.5 Threshold Value Check in Quantity Optimizing
1.2.2.1.6 Quantity Comparison for Schedule Lines in Sales Orders
1.2.2.1.6.1 Example of Quantity Comparison in Quantity Optimizing
1.2.2.2 Investment Buying
1.2.2.2.1 Requirements Determination Procedure for Investment Buying
1.2.2.2.2 Analysis Functions in Investment Buying
1.2.2.3 Load Building
1.2.2.3.1 Automatic Load Building
1.2.2.3.2 List of Results for Automatic Load Building
1.2.2.3.3 Manual Load Building
1.2.2.3.4 Additional Planning
1.2.2.3.5 Analysis Tool for Load Building
1.2.2.3.6 Management Vendor Service Levels
1.2.3 Dealing in Perishables
1.2.3.1 The Perishables Processing Procedure
1.2.3.1.1 Handling Perishables Using Allocation Tables
1.2.3.1.2 Handling Perishables Using Collective Purchase Orders
1.2.3.1.3 Handling Perishables Manually
1.2.3.2 Perishables Planning List
1.2.3.2.1 Configuring the Perishables Planning List
1.2.3.2.2 Environment Information and Options for Going to Other Functions
1.2.3.3 Procuring Perishable Produce
1.2.3.3.1 Determining Perishables Requirements
1.2.3.3.2 Buying Perishable Produce Over the Phone
1.2.3.3.3 Procuring Perishables at the Market
1.2.3.4 Issuing Perishable Produce
1.2.3.4.1 Issue List
1.2.3.4.2 Maintaining Sales Prices for Perishable Produce
1.2.4 Vendor-Managed Inventory (VMI)
1.2.4.1 VMI: Transferring Stock and Sales Data
1.2.4.1.1 Transferring Sales/Stock Data to Vendors
1.2.4.1.2 Transferring Stock/Sales Data to the Vendor: Procedure
1.2.4.1.3 Determination of Stock and Sales Data
1.2.4.1.4 Comparison Quantity
1.2.4.1.5 Determination of the Articles Affected
1.2.4.2 VMI: Receiving Stock and Sales Data
1.2.4.3 VMI: Planning Replenishments for Customers
1.2.4.3.1 Customer Replenishments
1.2.4.3.2 Displaying Transferred Stock and Sales Data
1.2.4.3.3 Analyzing Customer Stock and Sales Data
1.2.4.3.4 Customer Replenishments Planning
1.2.4.4 VMI: Generating POs for EDI Order Acknowledgments
1.3 Invoice Verification
1.4 Calculating the Planned Delivery Time
1.5 Subsequent Settlement
1.5.1 Subsequent Settlement Procedure
1.5.2 Rebate Arrangements in Subsequent Settlement
PUBLIC Page 3 of 99
1.5.2.1 Rebate Arrangement Processing (Vendor)
1.5.2.1.1 Creating a Rebate Arrangement
1.5.2.1.2 Creating a Rebate Arrangement Using the Referencin
1.5.2.1.3 Extending a Rebate Arrangement Using a Report
1.5.2.1.4 Manually Extending a Rebate Arrangement
1.5.2.2 Retrospective Creation of Rebate Arrangements
1.5.3 Conditions in Subsequent Settlement
1.5.3.1 Main Conditions in Subsequent Settlement
1.5.3.2 Scaled Conditions in Subsequent Settlement
1.5.3.3 Period-Specific Conditions in Subsequent Settlement
1.5.3.3.1 Example of Final Settlement for Period-Specific Conditions
1.5.3.3.2 Processing Period-Specific Conditions
1.5.4 Business Volume Updating in Subsequent Settlement
1.5.4.1 Purchase Orders and Price Determination in Subsequent Settlement
1.5.4.2 Updating Business Volume from Customer Settlement Documents
1.5.4.3 Business Volume Updating in Subsequent Settlement (Process)
1.5.4.3.1 Example of Business Volume Update for a Condition
1.5.5 Subsequent Updating of Business Volumes
1.5.5.1 Updating of Business Volume Retrospectively
1.5.5.2 Document Index for Retrospective Business Volume Update
1.5.5.2.1 Subsequent Compilation of the Document Index
1.5.5.3 Recompilation of Business Volume Data and Incomes
1.5.5.3.1 Compiling Business Volume Data (Report)
1.5.5.3.2 Compiling Rebate Income Data (Report)
1.5.5.3.3 Creating a Worklist
1.5.5.3.4 Processing a Worklist (Report)
1.5.6 Business Volume Comparison in Subsequent Settlement
1.5.6.1 Carrying Out Business Volume Comparison and Agreement
PUBLIC Page 4 of 99
1 Purchasing
Use
The functions available in Purchasing support the daily operations involved in the procurement of merchandise and settling up with vendors. The purchasing
functionality can be used both centrally in head office and locally in stores.
Integration
Purchasing comprises the following areas:
Requirements Planning
Purchasing is divided into the following areas: Replenishment Planning involves the determination of each individual site’s merchandise requirements. A
number of manual and automatic planning methods are contained in the system.
The actual planning run takes place is Requirements Planning. Here the system determines individual requirements, taking thedelivery point into
account. Purchase requisitions are generated.
Allocation
During allocation you can centrally distribute merchandise among a large number of recipients (for example, stores). The allocation documentation is
available in the Merchandise Logistics and Merchandise Distribution area.
Ordering
The functions in this area are used to order articles for which requirements were determined in the planning run. It comprises quantity optimizing, supply
source determination, conversion of purchase requisitions to purchase orders and purchase order monitoring.
Invoice Verification
Invoice Verification enables vendor invoices to be checked and supplies data for Rebate Processing. Invoice receipt by EDI is also supported.
Subsequent Settlement
This function facilitates the settlement of volume-based rebates and other arrangements. Conditions are entered in the system, and settled at the end of
a period of at the end of an arrangement.
Agency Business
The functions in the Agency Business area allow you to process trading contracts in which your role is agent or payer.
Seasonal Procurement
Seasonal procurement is a user-friendly, end-to-end, controllable order process, for example, for the area of fashion. Purchasing budget and date
management functions are integrated.
See also:
Supply Source Determination
Order Optimizing
1.1 Requirements Planning
Purpose
Requirements planning involves ensuring that goods are available when recipients (stores or customers) and consumers require them. The quantities required
have to be procured in good time. The following activities are required:
Monitoring the stock
Taking sales and purchase orders of recipients into account
Creating forecasts
Calculating requirement quantities
Creating follow-on documents for procuring the merchandise
The stock planner has to define the suitable forecast, requirements planning and lot sizing procedures for each article.
The logistics concept underlying SAP Retail supports the following processes:
Direct delivery (third-party)
The vendor delivers direct to the recipients. In this case, purchase orders are placed by either the recipient or the distribution center.
Delivery via the distribution center
The vendor delivers to a distribution center. The distribution center handles all further supplies to the recipients. Supplies can be handled as follows:
Putaway/removal from storage
The goods are put into storage following goods receipt and later removed from storage for delivery to the recipients.
Cross-docking/flow-through
The goods are not put away, but flow through and out of the distribution center. In the case of cross-docking, entire shipments (such as full pallets) are brought
from the goods receipt zone to the goods issue zone.
In the case of flow-through, the shipments are broken down into smaller units before they can be assigned to a particular recipient (for example, when a
recipient is only to receive half a pallet).
1.1.1 Basic Principles

The following is an overview of the requirements planning methods used in SAP Retail.

PUBLIC Page 5 of 99
Use
In Requirements Planning, the system uses the supply source determination function to decide how to procure merchandise. The system finds either a
distribution center (an internal source of supply) or a vendor (external source of supply).
Features
For more detailed information on the features of the function and on how to proceed, see Supply Source Determination .
1.1.1.2 Requirements Planning: Forecast
Use
A forecast of future requirements, based on past consumption figures, is needed to support some requirements planning methods. In some cases, the forecast
is compulsory, in others, it is used to provide additional, optional information. The forecast is carried out before requirements are planned. Examples of areas
in which a forecast is used are:
Time-phased planning
You must carry out a forecast before requirements are planned, as this is the only way to effectively cover requirements up to the next date on which
requirements are planned.
Automatic reorder point planning
In this process, you are advised to carry out a forecast before requirements are planned. The system uses the results of this forecast to calculate the current
reorder point and safety stock on the basis of a service level entered by you.
Replenishment
For replenishment, you only need to carry out a forecast if you use a dynamic target stock based on a target range of coverage and a forecast requirement.
Features
A number of forecast models are available for the forecast, such as constant, trend, and seasonal models, as well as models for moving average values and
weighted moving average values. You can assign a forecast model manually, or have the system determine one.
You control the forecast in the logistics data of the article master by maintaining parameters such as the number of historical periods and factors for
exponential smoothing.
If you make the appropriate settings in the forecast data of the article master, you can ensure that consumption figures for promotional goods are smoothed for
the forecast by the creation of an average value. In this process, a group of related promotional periods is first determined. The consumption values in these
promotional periods are then replaced by the average consumption value of the periods either side of the promotion.
You can simplify master data maintenance by creating a forecast profile containing parameter values that come up again and again, and then assigning this
profile to several articles. You can also copy forecast data for a new article master from a reference article.
For further information on forecasts, see MM - Materials Management , MM - Consumption-Based Planning .
1.1.1.3 Requirements Planning: Forecast With Alternative

Historical Data
Use
With forecasting using alternative historical data (AHD), you can create a forecast that is based on freely definable data. Forecasting using alternative
historical data is therefore not based on past consumption values that were updated in sites during goods issue posting.
PUBLIC Page 6 of 99
Using alternative historical data has the following advantages:
Improvement in the accuracy of the forecast for distribution centers (avoidance of the bullwhip effect).
Reduction of stock in the distribution center by lowering the safety stock.
Increase in revenue by avoiding missed sales.
However, note the following constraints that can arise as a result of using alternative historical data for the forecast.
The use of alternative historical data for forecasting is not a replacement for or an alternative to the forecast with consumption values from the past.
It only makes sense to use alternative historical data for the forecast if it is not possible or would be very difficult to show the requirements history for an
article using the consumption values from the past.
Using alternative historical data increases the possibilities for the planning process as a whole. The function has to be incorporated into the whole
process in addition to the other processes.
You should use the functions with caution as they do cause an increased load for the system and can impair performance for a long time.
Implementation Considerations
With the different MRP procedures, you use a forecast of future requirements to support requirements planning. Normally you would create such a forecast
with data that is based on consumption values from the past.
However, using consumption values from the past for a forecast can in some circumstances lead to less than optimum results. You should use alternative
historical data if the data basis of consumption data from the past for an article is incomplete, faulty or of poor quality. A second case when it makes sense to
use alternative historical data is if the existing consumption values do not reflect the actual requirements adequately enough.
Example
For example, the consumption value of an article may not be the optimum basis for a forecast if the consumption value is based on goods issues that are
misleading due to shortages. In this case, you should consider a forecast using alternative historical data. The forecast should be carried out on the basis of
purchase order quantities, provided that the purchase order quantities represent the requirement situation of the article more accurately. A further possibility
would be to use aggregated sales quantities from the stores that are supplied.
Integration
In principle, alternative historical data can come from any data source.
In SAP ECC, a technical link to the component SAP BW is provided as standard, which you can use to load alternative historical data into SAP ECC.
You can link to any other data source using the Business Add-Ins (BAdI) provided.
1.1.1.3.1 Alternative Historical Data
Use
You can improve the accuracy of forecasting by using alternative historical data (AHD) as the data basis for forecasting for the process of consumption-based
planning.
In this context, alternative historical data can be seen as freely definable data sources containing historical data, which can be used for forecasting in stores or
distribution centers.
Note that the alternative historical data function should only be used in certain cases. For more information on the use of alternative historical data, see
Requirements Planning: Forecast using Alternative Historical Data
Integration
In order to use alternative historical data for forecasting, you need to load data from freely definable data sources in table WAHD of SAP ECC.
In the standard system, a scenario is delivered for which the alternative historical data is loaded from the component SAP BW to SAP ECC.
In principle, you can take alternative historical data from any other data source. You can link such data sources using the Business Add-Ins provided.
Prerequisites
If you want to load alternative historical data from SAP BW, note the following requirements for this scenario:
1. The scenario requires suitable data to exist in SAP BW.Define which data from SAP BW is to be used as alternative historical data as the data basis for
a forecast. Note that a suitable query for the AHD scenario must be available in SAP BW.
2. Using Customizing for Data Retraction in SAP ECC (transaction MCW_AA) you can determine how and which data you want to load from SAP BW to
SAP ECC.
3. You can control alternative historical data from the Standard SAP ECC Customizing. The alternative historical data itself is controlled using RP types.
Features
Using the alternative historical data functions, you can maintain the consumption values as follows:
Using transaction WAHD1, you load alternative historical data into table WAHD in SAP ECC. You load the alternative historical data from the data
source you designated (for example, SAP BW). Once you have loaded the data, the alternative historical data is immediately available to use in
PUBLIC Page 7 of 99
forecasting.
With these functions, it is possible to look at the individual processes involved in loading the data using a flow trace. Use this function to help you
recognize and deal with any problems that may occur when loading alternative historical data. Logs that are generated are not saved.
These functions also enable you to work in a test mode. In the test mode, you can simulate the loading of alternative historical data, without the data
being posted to the database.
In order to achieve the best possible performance, you can process these functions in parallel. Use parallel processing when you want to process large
amounts of data.
Using transaction WAHD2, you can display alternative historical data for a combination of site and article and you can change this data. Use this
function to check and, if necessary, alter alternative historical data. You can also display other time series data, such as consumption values, forecast
values or the promotion smoothing of consumption values.
Using transaction WAHD3, you can display alternative historical data for a combination of site and article. You can also display other time series data,
such as consumption values, forecast values or the promotion smoothing of consumption values.
Using transaction WAHD4, you can delete alternative historical data for a combination of site and article. Use this function regularly to delete redundant
alternative historical data from the database table.
With these functions, it is possible to look at the individual processes involved in deleting the data using a flow trace. Use this function to help you
recognize and deal with any problems that may occur when deleting alternative historical data. Logs that are generated are not saved.
These functions also enable you to work in a test mode. In the test mode, you can simulate the deletion of alternative historical data, without the data
amounts of data.
You can carry out the functions for loading and deleting alternative historical data online as well as in the background. SAP recommends that you carry them
out in the background. Online processing is only recommended when processing very small amounts of data or for testing and simulation purposes.
Constraints
Loading alternative historical data is a very runtime intensive process.
Caution
In order to avoid runtime bottlenecks, you should make sure whether, and above all to what extent, it is worth loading alternative historical data.
You should only load the complete alternative historical data if really necessary, for example, if you need to make significant changes to the existing
delivery relationship. Otherwise you should just load missing periods.
1.1.1.3.2 Post Distribution Forecasting
Use
Post Distribution Forecasting (PDF) is a special way of making data available for forecasting for a distribution center.
With Post Distribution Forecasting, the aggregated consumption values of all recipients (plants and/or customers) supplied by this distribution center are used.
The aggregated consumption values come from the alternative historical data (AHD).
Use the Alternative Historical Data function, to provide aggregated consumption values for a distribution center for forecasting.
Prerequisites
In order to create a meaningful forecast for a distribution center based on aggregated consumption values of all the recipients (plants and/or customers)
supplied by this distribution center, you need to know which recipients are supplied by the distribution center.
As this information is not contained in the master data for the distribution center, you can establish an exact portrayal of the delivery relationships between a
distribution center and its recipients using the “ Delivery Relationships for Post Distribution Forecasting ” function.
You can use the delivery relationships determined to carry out an exact Post Distribution Forecasting for a distribution center.
You can also perform Post Distribution Forecasting without determining delivery relationships. In this case, however, you should make sure that you actually
do take all recipients into account. It is, for example, not necessary to determine delivery relationships for Post Distribution Forecasting if all recipients are
only supplied by one distribution center. It is also unnecessary if each recipient is only supplied by one particular distribution center.
For more information, see Requirements Planning: Using Delivery Relationships
1.1.1.4 Requirements Planning: Using Delivery Relationships
Use
You can use the delivery relationship function to determine which recipients (plants and/or customers) are supplied by a distribution center and with which
articles.
It is useful to determine delivery relationships if a forecast is carried out for the distribution center on the basis of consumption values for the recipients
supplied by this distribution center ( Post Distribution Forecasting ). As it is not possible to enter any information in the master data of the distribution center
about which recipients are supplied by a distribution center, it is necessary to restrict the recipients that are supplied.
PUBLIC Page 8 of 99
To be able to use the functions, you need to make the settings in Customizing. In Customizing for determining delivery relationships, you can determine how a
determination takes place. Here you set up profiles for determining delivery relationships.
You can also determine in Customizing which document types the system should use to determine delivery relationships between the distribution center and
recipients. If you want to determine recipients using the ‘ existing documents ’ method, use these Customizing settings to create further restrictions for
determining delivery relationships using document types.
Features
Using the delivery relationship features for Post Distribution Forecasting, you can maintain delivery relationships as follows:
With transaction WDRD1, you determine the delivery relationships.
With these functions, it is possible to look at the individual processes involved in determining the delivery relationships using a flow trace. Use this
function to help you recognize and deal with any problems that may occur when determining delivery relationships. Logs that are generated are not
saved.
These functions also enable you to work in a test mode. In the test mode, you can simulate the determination of delivery relationships, without the data
amounts of data.
With transaction WDRD2, you can display and change the delivery relationships that are determined. Use this function to check and, if necessary, alter
delivery relationships.
With transaction WDRD3 you can just display the delivery relationships.
With transaction WDRD4 you can delete the delivery relationships determined. Use this function regularly to delete delivery relationships that are no
longer required from the database table.
With these functions, it is possible to look at the individual processes involved in deleting the delivery relationships using a flow trace. Use this function
to help you recognize and deal with any problems that may occur when deleting delivery relationships. Logs that are generated are not saved.
These functions also enable you to work in a test mode. In the test mode, you can simulate the deletion of delivery relationships, without the data being
posted to the database.
amounts of data.
You can carry out the functions for determining and deleting delivery relationships online as well as in the background. SAP recommends that you carry them
out in the background. Online processing is only recommended when processing very small amounts of data or for testing and simulation purposes.
Constraints
Determining delivery relationships is a very runtime intensive process.
Caution
In order to avoid runtime bottlenecks, you should make sure whether, and especially to what extent, it is worth determining delivery relationships.
If a determination has been set at material level, the method of determination and the scope of the checks should be kept down to a minimum.
Delivery relationships should only be completely redetermined if really necessary (that is, for significant changes to the existing delivery relationships) and
should not be carried out all at the same time for large amounts of data.
1.1.1.5 Requirements Planning: Quantity Allocation (Push)
Use
In the process of pushing merchandise through to stores, you can allocate quantities on the basis of information and planning figures determined centrally,
without needing to know recipient requirements. This method is used in the following cases, for example:
First-time distribution of a new article
Distribution of promotional merchandise
Distribution of remaining stock
Distribution of one-time, fashion articles
Features
Allocation
The allocation table enables you to distribute merchandise to a large number of sites centrally. You can plan merchandise distribution and then trigger the flow
of merchandise by creating follow-on documents. The allocation table supports all variants of the SAP Retail logistics concept, that is, the direct delivery of
goods from the vendor to the recipient (third-party delivery), and the delivery of goods to the recipient via a distribution center.
For further information, see Allocation .
Promotion
Promotions are used to boost sales, or increase customer awareness of new merchandise, for example. When planning a promotion, you can use data from
the information system relating to past promotions. In a promotion, articles are usually offered at a lower price. In SAPRetail, you can create both retail
promotions (for store sales) or wholesale promotions (with special pricing for known customers in your customer master data).
Promotions that have the intention of reducing stock are not relevant for Requirements Planning, since the merchandise does not need to be procured. If
PUBLIC Page 9 of 99
merchandise is procured once only, it is generally allocated centrally. To do this, you can generate an allocation table with reference to the promotion in
promotion subsequent processing.
If an article is procured on a regular basis, and is temporarily part of a promotion, the sales of the article generally increase. As a result, in the case of time-
phased planning, the system informs the stock planner of any impending promotion.
If you make the appropriate settings in the forecast data of the article master, you can ensure that consumption figures for promotional goods are smoothed for
the forecast by the creation of an average value. You can only use smoothing with SAP Retail .
For further information, see Promotion .
1.1.1.6 Requirements Planning: Determination of Requirements

(Pull)
Use
‘Pull’ Method of Distribution in the Strict Sense
In the strict sense , a ‘pull’ method of distribution is one in which you react directly to consumer requirements over several steps in the supply chain.
In SAP Retail, you could pull merchandise back through the supply chain as follows:
First level: Stores
For requirements planning in the store, you use Replenishment, which is able to analyze sales immediately in POS inbound processing. In Replenishment,
warehouse orders are then created as follow-on documents. Order quantities are not optimized, to ensure that requirement quantities are transferred
unchanged, in line with the classic pull method.
Second level: Distribution center
In the distribution center, the warehouse orders created in Replenishment are grouped together to create a collective purchase order for the vendor. As a result,
consumer sales figures are passed on directly to the vendor.
‘Pull’ Method of Distribution in the Wider Sense
In the rest of this section, however, the ‘pull’ concept is enlarged to cover all requirements-driven planning transactions . This therefore includes
transactions that only comprise one step in the supply chain, for example, and those in which consumer requirements are forecast on the basis of historical
consumption data.
Features
Replenishment
Replenishment is a method of requirements planning designed especially for use in stores. Technically speaking, it can also be used in distribution centers.
Replenishments planning is based on the article stock, which is managed either by MM Inventory Management or simplified Inventory Management for
Replenishment. Stock levels are reduced as a result of article sales, which are registered as goods issues in POS inbound processing. Depending on the
method used, all other goods movements may be included in this stock. In replenishments planning, follow-on documents are created for procurement and
delivery.
For further information, see Replenishment .
Collective Purchase Orders
Collective purchase orders are used to plan merchandise distributions. The merchandise is ordered from a vendor and delivered to a distribution center, where
it is distributed to the individual recipients. You can use a collective purchase order to combine the requirements of recipients, which may exist in the system
as warehouse orders or sales orders, to create a single order for a vendor.
Distribution data for a collective purchase order is kept in the system and you can then use this to control and monitor the distribution of merchandise to
recipients. This data is accessed for cross-docking and flow-through, for example. In addition, a collective purchase order allows you to make better use of
vendor conditions, such as quantity discounts.
For further information, see Collective Purchase Order .

Consumption-Based Planning
Consumption-based planning is particularly suited for use in distribution centers. However, it can also be used for stores. Inventory management on a quantity
and value basis is a prerequisite for this planning method. As a result of planning, purchase requisitions are created, and these are then automatically
converted to purchase orders. Consumption-based planning also enables you to carry out time-phased planning.
For further information, see MM - Materials Management , MM - Consumption-Based Planning .

Online Planning
Online Planning enables you to plan online the procurement of merchandise from external vendors. Online Planning is designed for use in distribution centers.
It can, however, be used in stores (to order from external vendors). It enables you to check and change existing purchase orders (to meet minimum order
criteria, for example). You can also create new purchase orders.
Online Planning can be based on the results of automatic requirements planning. This option is only available, however, if purchase orders already exist, that
is if purchase requisitions have already been converted to purchase orders (see Reference Scenario ).
For further information, see also Online Planning .
Immediate Manual Planning (Planning Requirements for Perishables)
This procedure was designed for requirements planning for fresh produce, and is therefore referred to as requirements planning for perishables in SAP Retail.
The functions for requirements planning for perishables can also be used for non-perishable articles that nonetheless make similar demands on the system.
For further information, see Perishables .
PUBLIC Page 10 of 99
Vendor-Managed Inventory (VMI)
In SAP Retail, vendors can carry out requirements planning as a service to their customers. In line with your efforts to achieve efficient consumer response,
this enables you to work closely together with vendors/manufacturers as "allies" in the supply chain. This gives you the opportunity to improve your vendor
service level and at the same time reduce stock on-hand.
For further information, see Vendor-Managed Inventory .
1.1.2 Planning Workbench
Use
The Planning Workbench is a working environment for stock planners. It includes the Online Planning function and a connection to Internet Services . The
stock planner can use the Online Planning function to order merchandise from external vendors. Using the ordering days (order cycle) defined, you can have
the system suggest which vendors to order from and display the purchase orders that have already been created for the vendor. You can then decide whether
additional quantities or articles have to be ordered.
The Planning Workbench provides you with a worklist, from which you can go directly to the application (such as the Online Planning application) at the click
of the mouse. The worklist is easy to navigate through and can be displayed in a number of formats to suit yourself, as can the application.
Prerequisites
You can only use the Planning Workbench if you use SAP Retail .
Features
The main features of the Planning Workbench include:
Use of the Online Planning application
Display of the worklist in tree format (navigation is simple)
Display of additional information for entries in the worklist (for example, you can go from Online Planning directly to site and vendor master data)
Display of a personal selection of Internet links in the worklist and execute the links directly
Display of a personal selection of mail addresses in the worklist and execute the mail program directly
Worklist can be displayed in different formats, including:
Switching off of headers
Switching off of selection parameters
Variable structure
Variable sort sequence of the entries in the worklist
The application can be displayed in different formats (for example, generic articles can be displayed in exploded form)
Each user’s personal settings can be saved (start variant) and displayed automatically the next time the Planning Workbench is opened
1.1.2.1 Working with Worklists
Use
The Planning Workbench enables you to process the worklists in an application (such as Online Planning) with a high degree of convenience. You can display
additional information for the various items in the worklist.
The main functions in the Planning Workbench are available on the application toolbar of the worklist. Alternatively, you can call up all the functions from the
context menu (by clicking on the right mouse button while the cursor is on an object in the worklist).
Features
Tree Display
The worklist is displayed as a tree structure. The first level contains the applications in which you work (for example, Online Planning or Internet Services).
The level immediately below this contains the application-specific worklist, arranged by organizational unit.
The standard configuration of the Online Planning worklist contains the following levels:
1. Site
1. Purchasing Organization
1. Purchasing Group
1. Order date
1. Vendor
1. ...
In this case, you would select the site you want to process and the relevant purchasing organization, and so on.
Display Options
You can change how the worklist is displayed via the settings for the application. For example, you can:
Switch off heading (for example, the Site heading in the Online Planning worklist)
Switch off individual selection parameters (for example, all vendors)
Change the sequence of levels
Displaying Additional Data
The processing status of each entry is displayed as a stop light next to the entry. Initially, the stop light is red. When you start the application to process the
entry, any entries that have already been processed are displayed in yellow. As soon as you save the entry you are processing, the stop light changes to
green. By double-clicking on the stop light, you can change the status manually.
Note
Entries only maintain their status while you are processing the worklist in the current session. When you call up the transaction again, all the stop lights
are reset to red.
If you configure the worklist to display additional data (the General Settings tab), symbols for the various types of information are displayed next to the entries
in the worklist. The following table explains which types of additional data are available:
Additional Data Prerequisites What Happens If You Select Symbol
Master Data Display the symbol for Change object or Display Transaction started for displaying master data (for
object indicator set and maintenance/display example, site master data, vendor master data)
possible
Internet Link Display the symbol for Internet page indicator set Browser is started and connection to the web page is
and web page maintained in master data of object established (for example, to the vendor’s homepage)
Mail Address Display the symbol for E-mail indicator set and e- The mail program is started with the address as the
mail address maintained in master data of object recipient (for example, mail to a vendor)
Self-defined information (for example, information that User Exit EXIT_SAPLWOD2_002 is maintained for No action.
allows the associate to identify purchase orders that Online Planning
do/do not require processing)
Application Toolbar for the Worklist Area

The screen area of the worklist contains a separate application toolbar which you can use to process the worklist. You have the following options:
Execute
This executes the function for the entry you have selected in the particular application (for example, order processing in Online Planning)
Maintain settings
If you want to change the settings, you can go from the worklist directly to the initial screen of the Planning Workbench. You can also save your settings as a
start variant (see Activities). The variant is assigned personally to you and is always used when you call up the Planning Workbench.
Complete expansion of the selected node
Search for character string of your choice
Sort
In addition to the sort methods contained in the standard system, you can integrate your own methods for sorting the worklist in Online Planning using user
exit EXIT_SAPLWOD2_001 .
Refresh the display
The worklist is refreshed in line with its actual size.
If the Hide processed worklist indicator is set on the settings screen (the General Settings tab), all the objects in the worklist with the status green are
removed from the display.
Help on the working environment via an information button
Activities
To define a start variant on the settings screen, proceed as follows:
1. Enter the required settings and save them as a variant (for example, as "my variant").
1. Choose Edit Start variant.
1. Enter the required start variant (for example, "my variant").
1. If you want to skip the settings screen in future and go straight to the worklist, set the Skip settings indicator here. This enables you to reduce the
number of steps required.
1. Choose Save .
1.1.2.2 Online Planning
Use
Online Planning combines the benefits of an automatic planning procedure with those of ordering manually. You can have the system suggest external
vendors, articles and order quantities that you then verify based on other information. Since a stock planner in the retail trade often has to deal with up to a
hundred vendors a day and up to a hundred articles for each vendor, SAP has made every effort to make the online planning process as simple and efficient
as possible. All the information you require is contained in the one easy-to-read screen, including:
The articles offered by a vendor
The purchase orders placed with this vendor
Information important for planning requirements (such as the current stock on-hand, current purchase orders, sales figures for the last periods)
Information about the articles (such as the content of each order unit)
In Online Planning, you can plan articles for which a requirement was determined and also articles for which no requirement was determined (for example, to
enable you to achieve certain minimum order criteria). To enable you to do this, you can select all the articles supplied by a vendor.
This means that you can order items from a vendor on the days defined as regular ordering days, even though the article is not yet required.
Prerequisites
Online Planning can only be used for procuring merchandise from external vendors.
Integration
Online Planning has been developed from the additional planning function. Additional planning allows you to select all the articles carried by a vendor on the
order entry screen and add extra items to an existing purchase order.
In this way, you can order additional articles that were not suggested by the automatic planning run (for example, to make full use of the capacity in the means
of transport used). As of the current release, you should use Online Planning instead of additional planning for external vendors.
Features
Online Planning offers the following features:
Creation of a worklist with the following options:
Selection of a worklist based on the ordering days defined for the vendor
Arrangement of the worklist by distribution center and vendor
Freely definable layout of the worklist (you can change the sort sequence, for example)
Link from the worklist to displaying additional information (for example, site or vendor master data)
Link to an overview of forecast and consumption values for several periods, including the following detailed information for each period:
Forecast value
Actual consumption
Manually corrected consumption
Smoothed consumption (for promotions within a period)
Order quantity suggestion, for example based on the following procedure:
Specified range of coverage in days
Quantity from the last purchase order
Own method (via user exit EXIT_SAPLWFOD1_003)
Display of the planning list in ABAP list viewer format for easy printing
1.1.2.2.1 Reference Scenario
Purpose
You can use Online Planning both for checking the results of automatic planning and on its own. The following figure illustrates possible uses:
You can use Online Planning to verify existing purchase orders and include additional items in them. It can also be used to order articles even if no purchase
orders have already been created. You can have the system suggest vendors, articles and order quantities that you then verify based on other information.
In Online Planning, you can plan articles for which a requirement was determined and also articles for which no requirement was determined (for example, to
enable you to achieve certain minimum order criteria).
Process Flow
The following is an example of a typical scenario:
1. The consumption-based planning run is executed for a distribution center, resulting in purchase requisitions.
1. The purchase requisitions are converted to purchase orders.
1. The stock planner in the distribution center calls up Online Planning and creates a worklist for all vendors from which the company usually orders that
day.
He enters the following selection parameters:
Site: the distribution center for which he is responsible
Site category: "Distribution center"
Purchasing organization: the organization to which he is assigned
Purchasing group: the group to which he is assigned
Purchase order date: today’s date
1. The vendor looks through the purchase orders that have been created for each vendor.
1. For each purchase order, he selects additional articles from the vendor. Since the system did not report any requirements for these articles, he has the
system use the range of coverage to suggest how much to order.
1. The stock planner includes some of these articles in the existing purchase orders to optimize the orders (and reach the minimum order quantity, for
example).
1. The stock planner saves the changed purchase orders as well as those he created new.
Results
These include:
Items in an existing purchase order are changed.
Other items are added to an existing purchase order.
New purchase orders are created.
1.1.2.2.2 Settings
Use
The first time you use the Online Planning function, you have to make settings for the selection and for how the worklist is displayed. Normally, you probably
work with the same settings each time. These can be saved as a variant and used every time you call up Online Planning (see Activities under Working with
the Worklist ).
Integration
The settings you make here affect:
the objects selected and the appearance of the worklist
the appearance of the order items when you call up the order generation function from the worklist
When the worklist is generated, the system also uses the planning cycle maintained in the vendor master and purchasing group assignments.
Features
The settings you can make include:
Selections for worklist
You can narrow down the worklist based on organizational levels (such as site and purchasing organization) and time factors (such as purchase order date and
horizon).
Article selection - order items
You can specify selection criteria (for example, order cycle or merchandise category) for the articles to be ordered.
Default data for order items
You can specify data that the system should use for the order items when it generates purchase orders from the worklist.
Control data for order items
The settings you make here influence the make up of the purchase orders (for example, as a result of automatic rounding or a listing check).
Application settings
This is where you define the sort sequence in the worklist.
Settings for worklist
This is where you define how the worklist is structured.
1.1.2.2.3 Using Online Planning
Use
The following procedure is an example of how you call up the Planning Workbench and process a worklist in it.
Procedure
1. On the Planning Workbench screen, choose the Online Planning function and make the settings for worklist selection.
Normally, you probably work with the same settings each time. These can be saved as a variant and used for the selection every time (see Activities under
Working with the Worklist ).
For further information about settings, see Settings .
1. Choose the Internet Services tab.
If you require certain information from the Internet for your work, enter the Internet links here.
If you send regular mails to certain people, enter their mail address here.
1. Then choose the General Settings tab and make the settings that define how the worklist is displayed.
1. Choose Program Execute.
The worklist is displayed.
1. Look at the worklist and change the display to suit yourself.
You can, for example, expand different levels, sort the content in a different way or search for specific items in the worklist.
1. Position the cursor on the level for which you want to generate purchase orders.
The position of you cursor determines the part of the worklist to be processed.
1. Choose Execute in the application toolbar of the worklist.
The purchase order processing screen of Online Planning is displayed.
1. Gain an overview of the situation using the Environment and Goto functions. For example:
Goto Stock/requirements list
This list contains the current stock/requirements situation from the consumption-based planning perspective.
Goto Planning list
This list contains the current stock/requirements situation when consumption-based planning was last run.
Environment Promotions for site
1. Change the sort sequence if required by choosing Edit Sort.
1. Have the system suggest order quantities by choosing Purchase order Order quantity proposal.
1. Once you have checked all the parameters and the order quantity is correct, save the purchase order by choosing Purchase order Save .
1.1.2.2.4 Using User Exits to Adapt Online Planning
Use
User exists (enhancements WOD10001 and WOD20001 ) enable you to adapt Online Planning to suit your requirements.
Features
The following options are available for this:
Inclusion of additional fields in the planning list
Arrangement of the worklist to suit yourself
Display sequence to suit yourself
Inclusion of user-defined pushbuttons in the application bar
Checking of purchase orders based on user-defined criteria before saving
Order quantity proposal based on user-defined criteria
1.1.2.3 Order Cancelation
Use
The order cancelation function is used to change a large number or purchase orders or purchase order items at the same time.
Use this function to process purchase orders for which the delivery date falls in the past but which have not yet been delivered or have only been partially
delivered.
After consulting the relevant vendors, you can make the following changes to a freely definable selection of purchase orders:
Change the final delivery indicator.
Change the deletion indicator.
Change the delivery date.
The order cancelation function is integrated into the Planning Workbench. You can also call the order cancelation function using transaction WWP3.
You can execute the order cancelation function online and in the background.
Example
You want to transfer all internal purchase orders (for example, stock transport orders) from distribution center VZ01 to another distribution center. You only
want to consider purchase orders with a delivery date in the past. To do this you choose the push button "internal purchase order". In the "Criteria at Header
Level" section, the system now proposes the site category "store" and the supplying site type "distribution center". Change the site type to "distribution center"
as well and enter "VZ01" as the supplying site.
Now enter the delivery date in the "Criteria at Item Level" section. Leave the From field blank and enter yesterday’s date in the To field. The entries are now
complete. Press the Execute (F8) button. The system displays all the relevant purchase orders in a worklist for further processing.
1.1.2.4 Internet Services
Use
Internet links and mail addresses important for your work can be saved in the Planning Workbench. While processing a worklist, you can go directly from the
worklist to the Internet or to the mail program.
Prerequisites
You can also call up Internet services while displaying additional data for the individual entries in the worklist. You must previously have entered the required
Internet links and the mail addresses in the vendor and site master data. For further information in displaying additional data, see Working with the Worklist .
Features
Use of Internet Links
When you select an Internet link in the worklist, your browser is started and a connection is made to the web page concerned.
Use of Mail Addresses
When you select a mail address in the worklist, your mail program is started and the address selected entered as the recipient.
1.1.2.5 General Settings
Use
In the general settings, you can specify how you want the worklist to be displayed.
Features
You can, for example, define whether:
Objects successfully processed are to be hidden
Levels only containing one object are to be automatically expanded
1.1.3 Replenishment
Use
Replenishment is a method of supplying recipients (sites or external customers) with merchandise in line with the demand for the merchandise. In
replenishment planning, requirements are calculated using the current stock situation. When this has been done, follow-on documents (for example, purchase
orders or sales orders) are generated for supplying merchandise.
Replenishment for sites
Here you are running replenishment planning for an internal customer (for example, for a store) that has a site and customer master record in their system.
Replenishment calculates required quantities using previous goods movements and paying particular attention to sales entered at point of sales (POS) in store
and POS inbound processing that have been posted as goods issues.
Replenishment for external customers
Replenishment for external customers is used in Vendor-Managed Inventory (VMI) to run requirements planning as a service to customers. To run
replenishment for external customers, you must have access to customer sales and stock data. Fore more information, see Vendor-Managed Inventory (VMI)
.
A customer master record for your customer exists in your system. No site master record is available, however. You can use replenishment planning for
external customers both in an SAP Retail system and a manufacturing system.
Integration
Article (or material)
You can process article-related replenishment data using article maintenance (in an SAP Retail system) or using material maintenance (in a manufacturing
system).
Site
In the site master you maintain the different sets of data for controlling Replenishment. You can, for example, determine the type of follow-on documents that
are created.
Inventory Management
You can use Inventory Management in Materials Management as the basis for Replenishment.
POS Interface - Inbound
During POS inbound processing, the system analyzes sales data and updates the data as goods issues in Inventory Management.
Store Order
The system uses store order functions to generate follow-on documents after the replenishment requirements have been determined.
Features
Replenishment for sites
Determination of replenishment requirements based on stock data.
Simplified replenishment-based Inventory Management enables you to use replenishment for Inventory Management on a value-only basis.
Simplifying master data maintenance by grouping sites with similar requirements together in requirement groups.
Planned issues and receipts can be taken into consideration based on ATP (available-to-promise).
Sales orders, purchase requisitions, purchase orders or deliveries can be generated as follow -on documents for replenishment planning.
Analyzing results from replenishment runs in the Replenishment Monitor.
Replenishment for external customers
Determination of replenishment requirements based on stock data. You must have access to customer sales and stock data. Customers can transfer
this data to you by EDI in, for example, VMI (see VMI: Receiving Sales and Stock Data ).
Only replenishment-based Inventory Management can be used. You cannot use MM-based Inventory Management.
Planned issues and receipts cannot be taken into consideration.
Only sales orders are generated as documents following on from replenishment planning.
Goods receipts are not confirmed.
See also:
Background Processing: Replenishment
Multi-Step Replenishment
1.1.3.1 Replenishment: Inventory Management Types
Use
When using the Replenishment application component, you can manage inventory in one of two ways:
Materials Management-based Inventory Management
In this case Replenishment is based on the Inventory Management data from Materials Management of the ERP system. Each goods movement is
recorded in a document. You should use this type of Inventory Management as much as possible. It can, however, only be used for Replenishment if
you manage stocks on an exact article basis (not on a merchandise category basis).
Replenishment-based Inventory Management
You can activate replenishment-based Inventory Management by selecting the indicator in the replenishment article data for the article destined for the
relevant recipient.
Replenishment-based Inventory Management allows you to replenish stocks of articles managed in MM-based Inventory Management on a merchandise
category basis (value-only article). With replenishment-based Inventory Management, you can manage stocks for external customers for which there is
no MM-based Inventory Management data.
In replenishment-based Inventory Management, inventory is managed in a much simpler way than in Materials Management. The only figure relevant to
Replenishment for a particular article at a particular recipient is the stock on-hand. No goods movements documents are kept.
The following transactions/events can change replenishment stock:
Posting aggregated business volume data (message category WPUUMS ) or non-aggregated sales documents (message category WPUBON )
at POS inbound.
Generating follow-on documents in a replenishment run and the correction of replenishment stocks using document quantities. You can activate
corrections using document quantities in the replenishment article master data.
You can make manual corrections to the replenishment stock using the parameter overview in Replenishment.
Posting stock data sent by a customer using EDI (message category PROACT ) within Vendor Managed Inventory (VMI). Fore more information,
see Vendor-Managed Inventory (VMI) .
The following table illustrates the differences between the two types of Inventory Management:
Characteristics MM-based Inventory Management Replenishment-based Inventory Management
Number of stock types managed high only one
Materials movements documents created not available
Calculation of planned issues and receipts using ATP possible not possible
(Available-to-Promise)
Article-based stock data for value-only based Inventory not supported supported
Management
Inventory Management for customers (no site master not possible possible
exists)
Replenishment-based Inventory Management indicator not set set
1.1.3.2 Replenishment: Examples for using Replenishment

The following examples indicate possible uses for Replenishment. The initial situation for every example is outlined and then the way in which parameters
have to be set for Replenishment is represented.
"Standard procedure"
Situation:
Article-based Inventory Management has been activated for stores.
Sales are not forecasted.
Sales data from stores is confirmed via POS inbound.
Stores can order merchandise themselves.
Replenishment parameters
You use Materials Management-based Inventory Management; the indicator for Replenishment-based Inventory Management in the article master is,
therefore, not set.
You enter a materials planning indicator in the article master for static target stock.
You take planned issues and receipts into consideration when planning Replenishments .
Optionally, you can define a reorder point.
"Simplified procedure"
Situation:
You carry store stocks at value-only article level; MM-based Inventory Management is not article-based.
You do not execute sales forecasts at article/store level.
You confirm sales data from stores using POS inbound.
Replenishment parameters:
You use MM-based Inventory Management; the indicator for Replenishment-based Inventory Management in the article master is, therefore, set. You
can set the opening balance to zero or enter current stock, which has been defined externally, for example using a physical inventory count, manually.
You enter a materials planning indicator in the article master for static target stock. You can set the static target stock using the opening balance or a
value calculated outwith the system.
In the article data for Replenishment, you can activate the correction of replenishment stocks using the follow-on documents that have been generated.
Replenishment for Franchisees and in Vendor Managed Inventory (VMI)

Situation:
Customer master data is available. However, no site master data exists. In this example, MM-based Inventory Management cannot be used.
You can forecast sales at customer/article level using flexible planning (information structure S130).
In Franchising, customer sales data is confirmed for you via POS inbound. In VMI, customer sales data is confirmed via EDI (message category
PROACT ).
Replenishment parameters:
You use MM-based Inventory Management; the indicator for Replenishment-based Inventory Management in the article master is, therefore, set.
You can set the opening balance to zero or enter current stock manually, which has been defined externally, using a physical inventory count, for
example.
You enter a materials planning indicator in the article master for dynamic target stock.
In Replenishments planning, you take forecasted sales within the replenishment lead time into consideration.
Replenishments planning automatically generates sales orders (order type TAV ) as follow-on documents.
1.1.3.3 Replenishment: Master Data
Use
You can maintain data for Replenishment in the article and site masters.
Article master
You can define replenishment parameters and forecast data for Replenishment via article maintenance.
Site master
In the site master, profiles for store orders and POS inbound processing are required for Replenishment. You can also maintain requirement groups in the site
master.
1.1.3.3.1 Replenishment: Article Master Data for Sites
Use
The article master data contains various data that is relevant for Replenishment . If you want to use replenishment for sites (internal customers), use article
maintenance in SAP Retail to enter data.
Features
Maintenance levels
Recipient level
All data relevant to Replenishment is maintained on this level. This is the most detailed maintenance level for data relevant to Replenishment. You can
maintain replenishment parameters in the logistics data of an article for each site.
You can also enter replenishment parameters in the logistics data for external customers for which no site master records are maintained in the system. There
is a separate screen for entering this data. You can maintain the same parameters for a customer as for a site.
Requirement group level
Requirement groups make it easier to maintain data for a large number of recipients that are sites. If you maintain replenishment master data for an article at
requirement group level (via Extras), the data is copied to the site level, provided you have defined a requirement group in the site master for the merchandise
category, and the article is listed in the site.
Data types
The following data is maintained in article maintenance:
These include:
RP type
Replenishments can only be planned if you have entered an RP type defined for Replenishment. The RP type must be assigned the RP procedure W and a
planning method other than 1 (planned by external system). If the RP type is assigned the forecast indicator + (compulsory forecast), the target stock is
calculated dynamically in the replenishment planning run. If you want to plan using a dynamic target stock, you must have previously forecast the sales.
Types RP (replenishment planning with static target stock) and RF (replenishment planning with dynamic target stock) are defined as standard.
Reorder point
Safety stock
Replenishment-based Inventory Management indicator ( Replenish.IM)
If you flag the indicator, stocks are determined using Replenishment-based Inventory Management. If you do not flag the indicator, the system calculates
stocks using MM-based Inventory Management.
Indicator for correcting replenishment stock with document quantity.
This indicator only has an effect if Replenishment-based Inventory Management is used. If this indicator is set and replenishment is run, the quantities in
follow-on documents generated are added to the stock figure used for Replenishment and are thus considered as expected goods receipts. It makes sense to
set this indicator if the only information you have as the basis for Replenishment is store sales information.
Availability checks
You must enter a check group for the availability check in the logistics data for articles for which expected receipts and issues are to be included in the
planning run.
Forecasts
You can enter forecast data (for example, forecast models) in article maintenance for articles with Inventory Management on an exact article basis. The
forecast is based on Materials Management functions.
If no article data exists at site level (for example, when Inventory Management is on a merchandise category basis or for external customers), you run the
forecast using the flexible planning functions.
Replenishment block
An article can be blocked for Replenishment by using the following status in the article master:
General article status
You can choose to set this status either on the client level or the site level. If a block is set, an error message is generated in Replenishment planning. You
can determine the influence (for example, on Requirements Planning, Purchasing or Inventory Management) that a particular status may have in article
Customizing via control data. In order to affect Replenishment, you must set a block for requirements planning at the relevant status in Customizing.
Sales status
You can set this status at client level, for the distribution channel or the distribution channel/site level. If a block is set, an error message appears when
generating follow-on documents. You can determine the influence (for example, on sales orders or deliveries) that a particular status may have in article
Customizing via sales relevant data. In order to influence Replenishment, you must set a replenishment block in retail-specific article settings for the article
status for Retail functions.
1.1.3.3.2 Replenishment: Article Master Data for External

Customers
Use
You have to enter data in the article master to control the procedure and results of your replenishment planning. If you want to use Replenishment for external
customers, two possible maintenance scenarios exist:
Use transactions MM41 or MM42 (article maintenance) to maintain data in an SAP Retail System.
Use transaction MM01 or MM02 (material maintenance) to maintain data in an manufacturing system.
The data to be maintained is identical for both scenarios. This data is managed at customer level and it is therefore not assigned to a site.
Features
The data that you can maintain in article maintenance includes the following:
RP type
Replenishments can only be planned if you have entered an RP type defined for Replenishment. The RP type must be assigned the RP procedure
W and a planning method other than 1 (planned by external system). If the RP type is assigned the forecast indicator + (compulsory forecast),
the target stock is calculated dynamically in the replenishment planning run. If you want to plan using a dynamic target stock, you must have
previously forecast the sales.
Types RP (replenishment planning with static target stock) and RF (replenishment planning with dynamic target stock) are defined as standard.
Target stock
You must maintain the target stock only if you have assigned an RP type for replenishment planning with a static target stock. The static target
stock defines the stock figure for the article at the customer’s after goods receipt. In replenishment planning, the replenishment requirement is
calculated from the target stock as follows:
Replenishment requirement = target stock - current stock at customer’s
Reorder point
Safety stock
Target range of coverage
The target range of coverage indicates the number of days between the goods receipt for the current planning run and the following goods receipt.
Indicator for Replenishment-based Inventory Management ( Replenish.IM)
This indicator is always set. In Inventory Management (Materials Management), stock is always managed per site. However, it cannot be used to
manage stock for customers.
This indicator only has an effect if Replenishment-based Inventory Management is used. If this indicator is set and replenishment is run, the
quantities in follow-on documents generated are added to the stock figure used for Replenishment and are thus considered as expected goods
receipts. It makes sense to set this indicator if the only information you have as the basis for Replenishment is store sales information.
1.1.3.3.3 Replenishment: Structured Articles
Use
Replenishment allows you to calculate the requirements for a header article of a structured article based on the requirements for the relevant components. If
you run replenishment for the components and the components are not listed individually, the component requirements are converted into a header article
requirement.
Integration
The following general function is used to calculate the header article requirements based on the component requirements: Requirements Planning: Calculating
the Header Article Quantities Based on the Component Quantities .
Prerequisites
You can only use structured articles if you use SAP Retail .
You cannot list components individually for particular customers. Components should only be listed as components of structured articles. If components
are listed individually, they are also procured individually.
You must maintain replenishment data for each component in the article master.
You must enter a universal availability indicator for replenishment in the logistics data for header articles and related components.
Example
If you want to maintain the master data for a prepack and run replenishment for components, you must follow the sequence listed below:
1. Create a generic article (with variants)
Maintain the suitable replenishment data to be copied later into the logistics data at reference site level.
Enter the availability indicator ND in the logistics data at reference site level so that replenishment is not carried out for that article.
2. Create a bill of materials for a prepack, based on the generic article.
3. List the prepack.
Here, the prepack components, in this case the generic article variants, are also listed. In accordance with the default logic of the article master, the
replenishment master data is generated for the components in the listed sites.
1.1.3.3.4 Replenishment: Logistical Variants
Use
When generic articles have logistical variants, procurement variants can differ from the sales variant. If this is the case, procurement variants are used in
follow-on documents for replenishment. Replenishment therefore transfer procurement requirements to another variant. If more than one procurement variant is
assigned to the article in question, the system selects the variants that have been listed for the relevant store.
Prerequisites
You can only use logistical variants if you use SAP Retail .
1.1.3.3.5 Replenishment: Requirement Groups
When you have to manage a large number of sites or a large number of articles, you can reduce the effort required to maintain the large amount of data by
defining requirement groups. This prevents you from having to maintain all the data for every combination of site and article.
Prerequisites
You can only use requirement groups if you use SAP Retail .
Features
You create requirement groups for every merchandise category. A group comprises all the sites who have the same requirements in a particular merchandise
category and who therefore place the same demands on Replenishment.
You maintain requirement groups as follows:
1. You assign requirement groups to merchandise categories in the site master.
2. You list the articles for which you want to define requirement group values in all the relevant sites.
3. You maintain replenishment parameters in the article master at requirement group level (and not at site level).
If you have to change a parameter for an article for the whole requirement group, you only have to make one change. If a particular article is listed in a site, the
data at requirement group level is copied to site level.
You can maintain values for specific articles at site level that differ from the requirement group values. These values are treated as exceptions and are
protected from being over-written. Some data, such as the RP type, cannot be maintained at requirement group level. This data must be maintained at site
level.
1.1.3.3.6 Replenishment: Example of Requirement Groups Usage

The following example illustrates how the use of requirement groups affects Replenishment.
Requirement Group Assignment in the Site Master

The following table illustrates several site master records. A requirement group has been assigned to the confectionery merchandise category.
Sites Merchandise category Description Requirement group
R151 R1115 Confectionery 01 (large)
R153 R1115 Confectionery 02 (medium)
Replenishment Article Data at Requirement Group Level

Replenishment data has been defined at requirement group level for article R100002 (chocolate) in merchandise category R1115 (confectionery):
Requirement group Reorder point Target stock
01 (large) 90 300
02 (medium) 30 120
Replenishment Article Data at Site Level

The system copies the replenishment article data from requirement group level to site level. It does so based on the site group assignments made in the site
master.
Article Description Sites Reorder point Target stock
R100002 Chocolate R151 90 300
R100002 Chocolate R152 90 300
R100002 Chocolate R153 30 120
Every change made to the replenishment data at requirement group level is automatically copied to the sites. This makes it more convenient to maintain data
when a requirement group contains a very large number of sites.
Replenishment Data at Site Level with Exceptions

Even though site R152 is assigned to a requirement group, you change its reorder point to 80.
Article Description Site Reorder point Target stock
R100002 Chocolate R152 80 300
You then change the reorder point for requirement group 01 to 100.
01 (large) 100 300
This change is then made for all the sites assigned to the requirement group. The reorder point for site R152 differs from that for the requirement group. It is
therefore treated as an exception and not changed.
R100002 Chocolate R151 100 300
R100002 Chocolate R152 80 300
R100002 Chocolate R153 30 120
1.1.3.3.7 Replenishment: Site Master Data
Use
The following data for controlling Replenishment can be maintained in the site master. You can, for example, define suggested values for the type of generated
follow-on documents or assign requirement groups to merchandise categories.
Features
In the site master you maintain the following data for controlling Replenishment:
Store order control parameters
Replenishment uses the store order functions to create follow-on documents. You can maintain store order control parameters in a POS inbound profile in the
Customizing section for POS inbound. Profiles are assigned to sites.
You can also enter special profiles for Replenishment and the Store Order which you can then assign in the site master at merchandise category level.
The parameters relevant for Replenishment include:
Default setting for the document category
This controls the follow-on document created, for example, purchase orders or deliveries. You can enter different default values for every type of source of
supply (internal or external vendor). If no details exist, the system uses the general default value.
Default delivery type
If the follow-on document created is a delivery, you can enter a default document type for the delivery.
Error message control
POS inbound processing control
To control POS inbound processing, you assign a POS inbound profile to the site. Depending on the type of Inventory Management used (MM-based or
Replenishment-based), in the Customizing section for POS inbound you must adjust the process control in the POS inbound profile for:
Aggregated sales
Sales as per receipts
If you use MM-based Inventory Management, you must set the Inventory Management (IM) indicator. The indicator for updating Replenishment-based
Inventory Management should not be set.
If you use Replenishment-based Inventory Management, you must set the indicator for updating Replenishment Inventory Management . The Inventory
Management (IM) indicator should not be set.
Requirement group control parameters per merchandise category
You can assign a requirement group to each merchandise category in every site for Replenishment. The requirement group values for the site are thus copied
to all articles in the merchandise category listed in the site.
Requirements planning indicator
If you want to run replenishments using the net-change method, you must set the Requirements planning indicator in the listing/requirements planning data.
1.1.3.3.8 Replenishment: Check Consistency of Replenishment

Data
Use
You can use this function to manage the replenishment master data consistently and efficiently.
Replenishment is a special function in SAP Retail; it is not available in the standard system but rather is based on some of the functions and tables in the
standard system. Redundant data and inconsistencies in the master data may therefore occur. With the functions available up till now, it was not possible to
delete the space-intensive replenishment master data efficiently without archiving some master data at the same time.
You can execute the replenishment data consistency check function online and in the background.
Scope of Functions
Using this function, you can perform the following activities:
Consistency check
You use this activity to check for and eliminate inconsistencies in table WRPL. The system overwrites any inconsistent entries in table WRPL with
entries from the table MARC.
Deletion of replenishment data
You can delete any entries in tables WRPL and WRPT that are no longer required. The system only deletes entries that have an MRP type that is
not relevant for replenishment.
Deletion of requirement groups
If you maintain replenishment master data using requirement groups, you cannot delete the entries in table WRPP for all materials in a store. Set
this indicator if there are entries in table WRPP for materials that no longer exist in table WRPL and which therefore need to be deleted.
You can execute the replenishment data consistency check function online and in the background.
1.1.3.4 Replenishment: Forecasts
Use
In Replenishment, forecast data is used at two points:
In replenishment planning, you can consider forecasted sales to be expected issues. In doing so, sales are considered from the time of planning until the
end of the replenishment lead time.
If you work with dynamic target stock, target stock is calculated again in replenishment planning based on forecasted sales data. In this example, sales
are calculated based on the end of the replenishment lead time for the duration of the target range of coverage.
A number of models are available for running a forecast (for example, trend models or constant models). Whether you run a forecast using requirements
planning or flexible planning functions depends on the type of Inventory Management used.
Features
Forecast in Requirements Planning
If you use MM-based Inventory Management, you can run a forecast using the requirements planning functions. You maintain the forecast parameters for each
site in the article master. You can also select the periods in which the forecast values should be updated, for example, each day, week or month.
See also: Requirements Planning .
Forecast in Flexible Planning
If you use Replenishment-based Inventory Management, you can run a forecast using the flexible planning functions. Forecast parameters in flexible planning
are either entered online for each planning object (for example, a combination of recipient and article) or online in a forecast profile.
Before you can do this, you must have activated updating of the information structure S130 in the Retail Information System (RIS) that contains the forecast
data for Replenishment. The historical values for the application are determined using this structure. The period data for planning is defined in the information
structure and is therefore the same for all planning objects in the structure.
See also: Flexible Planning System .
1.1.3.5 Replenishment Planning
Purpose
Replenishment planning calculates replenishment requirements and then generates follow-on documents for procurement and delivery. Planning results will be
displayed in the replenishment monitor. Here you can see which follow-on documents have been created and which errors have occurred. You have the option
of carrying out replenishment planning in the system online or as a job.
In replenishment planning, the system differentiates between the following situations:
The recipient is a site (internal customer). This means that a site master record and a customer master record are assigned to this recipient in your
system.
The recipient is an external customer . This means that only a customer master record is assigned to this recipient in your system.
For more information about the differences between these two scenarios, see Replenishment .
Prerequisites
If you want to update stock information for replenishment using POS inbound processing, you must have completed processing before beginning
replenishment planning.
Process Flow
1. You can start replenishment planning manually (online) or in the background (in batch) for selected recipients and articles.
2. The system calculates expected stock at recipient at the end of the replenishment lead time.
3. If forecast data exists in the system, you can take the forecasted sales until the end of the replenishment lead time into consideration (see also
Replenishment: Forecasts ).
If Inventory Management in Materials Management is active, planned store issues and receipts until the end of the replenishment lead time can be taken
into consideration using ATP (see also Replenishment: Inclusion of Expected Receipts and Issues ).
4. The system calculates target stock.
5. Target stock can be calculated using replenishment article data (static target stock) or dynamically when replenishment planning is carried out (dynamic
target stock). You can only work with dynamic target stock if forecasted sales data exists (see also Replenishment: Example of Planning Using a
Dynamic Target Stock ).
6. The system calculates your required replenishment quantity.
7. The required replenishment quantity is the difference between the target stock and the standard stock. If you have maintained a reorder point, a required
replenishment quantity is only defined if the reorder point has not been exceeded (see also Replenishment: Using a Reorder Point ).
If, while planning replenishments, requirements are determined for components of structured articles, the system converts the requirement to that for the
header article. You can then enter the header article in the follow-on documents. If required, you can influence how the system converts the component
requirements to header article requirements via a user exit (see also Replenishment: Structured Articles ).
8. In manual replenishment planning, you can correct required replenishment quantities manually.
9. In online replenishment planning, the articles to be included in the replenishment run are displayed before follow-on documents can be generated. Data is
displayed using the ABAP List Viewer that enables you to, for example, filter or sort the data. Here you can also view the required replenishment
quantity for every article - you can change the quantity manually (for example, for test purposes). You can view a detailed screen for every item which
shows how required quantities are defined.
10. Follow-on documents are generated.
After requirements have been determined, follow-on documents are generated. You have to start this program manually on the screen for displaying
requirements. The system uses functions for store order processing to generate follow-on documents (see also Store Orders ). You can generate the following
documents:
Purchase requisition
Purchase orders
Deliveries
Sales orders
If no site master data exists for a recipient, a sales order is normally generated (order type TAV ). The system generates follow-on documents and optimizes
the quantities required. The replenishment quantity is the requirement quantity after it has been rounded off (see also Order Optimizing: Quantity Optimizing ).
You can generate follow-on documents in a test mode. Follow-on documents are only generated internally in test modes without data being written to the
database. The results from replenishment runs can be evaluated both in normal mode and test mode, using the replenishment monitor.
Results
If no errors are recorded, follow-on documents are generated for Replenishment. Each time you execute the program for planning replenishments, the system
stores the replenishment run under an internal number. This number is used to identify a transaction when you subsequently analyze the run in the
replenishment monitor. For further information, see Replenishment Monitor .
1.1.3.5.1 Replenishment: Inclusion of Expected Receipts and

Issues
Use
Stock in stores can change from when replenishment planning is executed and the stock is available for sale in stores. Receipts and issues can be cause
such changes. In replenishment planning, expected issues and receipts can be determined by the system and can be used when calculating requirements. In
doing so, planned receipts and issues as per ATP (available to promise) and forecast sales can be taken into consideration in the calculation.
The time period for taking expected receipts and issues into consideration begins on the planning date and ends when the replenishment lead time ends. For
articles with article-based Inventory Management in Materials Management (MM), the replenishment lead time is defined using article master data
(replenishment lead time = purchasing department processing time + planned delivery time + goods receipt processing time). You can also define the relevant
time period in replenishment planning for other articles.
See also: Replenishment: Including Expected Receipts and Issues .
Features
Receipts and Issues Based on ATP
To take planned receipts and issues into consideration, you must set the corresponding indicator in replenishment planning ( Define Receipts and Issues
Based on ATP ). If the indicator has been set for an item, an availability check is executed for the article for this item in the store when the "Replenishment
Lead Time" has ended. The available quantity calculated in this way represents corrected current stock which included the planned receipts and issues.
Using ATP, you can take purchase requisitions, purchase orders placed with external vendors, stock transport orders, and deliveries for stock transport orders
as receipts into consideration in the planning run. Deliveries not referencing a system document cannot be taken into consideration. Issues (for example,
reservations or sales requirements) are taken into consideration.
Planned issues and receipts can only be determined for articles with MM-based Inventory Management. Before you can use the ATP option, you must enter a
check group for availability checks in the logistics data in article maintenance for the relevant article. Check groups for the availability check can be
maintained in Customizing for Sales and Distribution. The check rule is defined internally for Replenishment as RP .
For a combination of check rule and check group, determine the ATP scope of check and use this to determine, for example, which documents are to be taken
into consideration as planned receipts. You can make a setting that determines if the availability check is to be executed with or without a replenishment lead
time:
Without taking the replenishment lead time into consideration
This setting is included in the standard delivery. This has the advantage that if two replenishment runs are executed in immediate succession for the same
article, requirements are calculated during the first run only. Planned issues (for example, sales orders) can, however, incorrectly increase current
requirements.
Taking the replenishment lead time into consideration
In order that issues planned for the future do not influence current requirements, you can execute the replenishment check taking the replenishment lead time
into consideration. In this situation, the ATP check confirms that every quantity is available at the end of the replenishment lead time because the quantity can
be procured by that date. Therefore, the ATP check is called for the day before the replenishment lead time ends, using Replenishment.
Issues Based on Forecast Sales
If you ran a forecast of future sales, you can include these values as issues in the calculation. To do this, you must set the indicator Forecast Include Issues
in replenishment planning.
In doing so, sales are considered from the time of planning until the end of the replenishment lead time. In dynamic target stock, sales from the end of the
replenishment lead time for the entire range of coverage (normally for the next two goods receipts) are normally included in the calculation.
In replenishment planning, the system takes sales on a daily basis into account. If you use a different period for forecasting (such as a week or month), the
system calculates average daily sales as follows:
daily sales = sales per period / number of working days per period
1.1.3.5.2 Replenishment: Including Expected Receipts and Issues
Starting Point
The following table shows a replenishment planning run that includes expected receipts and issues. The run results in replenishment requirements for this
week (week 0).
Week -2 -1 0 (today) 1 2
Target stock 200 200 200 200 200
Actual stock on-hand 160 145 160
Forecast stock 145 135 170 140 150
Expected receipts 55 65 30 60 50
Expected issues 60 50 50 50 50
Replenishment 30 60 50
requirement
How are replenishment requirements determined?

The replenishment requirement for the week is based on the target stock for the week and the forecast stock at the time of the goods receipt. In the example,
a replenishment lead time of two weeks is assumed. The replenishment requirement for the current week is calculated as follows:
Replenishment requirement (week 0) = Target stock (week 0)
- forecast stock (week 2)
= 200 - 150
= 50
How is forecast stock calculated?

The forecast stock for any future week is based on the actual stock on-hand for the current week and the expected receipts and issues from now until the
future week. In the example, a replenishment lead time of two weeks is assumed. The forecast stock for week 2 is calculated as follows:
Forecast stock (week 2) = Actual stock on-hand (week 0)
+ expected receipts (week 0)

- expected issues (week 0)
= 160 + 30 + 60 - 50 - 50
= 150
1.1.3.5.3 Replenishment: Planning Using Dynamic Target Stock

You are planning replenishments of article R100499 (chocolate) in store R151.
Article master
The following data exists for the article:
Parameter Value This means:
RP type RF Calculate target stock during planning phase
Replenishment run time 3 days Time required between DC R300 placing PO and store
R151 receiving goods
Target range of coverage 7 days Matches the delivery cycle: weekly deliveries, on
Thursday mornings
Safety stock 10 piece Stock should not fall below this level.
Maximum target stock 500 piece Stock should not exceed this level.
Minimum target stock Not defined Stock should not fall below this level.
Current stock 100 piece Stock level in store R151 on planning date
Forecasts
A forecast is run for the next four weeks for the article. The following values are produced:
Calendar week 20 21 22 23
Sales (in pieces) 240 300 240 240
Replenishment Planning
You plan replenishments on the Monday evening of week 20, taking expected receipts and issues into account. Since there is a replenishment lead time of 3
days, a stock transport order is generated as a follow-on document for the replenishment run. The stock can be delivered from distribution center R300 by
Thursday morning of week 20.
The planning run operates as follows (all quantities in pieces):
1. Calculation of the expected stock
1. The stock currently available (100) is determined.
2. Planned receipts and issues based on ATP are added (period: planning date until the end of the replenishment lead time).
3. No such transactions are planned between Monday evening and Thursday morning. The value is therefore zero.
4. Subtraction of the forecast sales (period: planning date until the end of the replenishment lead time).
The period taken into account is from Monday evening of week 20 to Thursday morning of week 20. Based on 6 working days a week, 40 pieces would be sold
per day in week 20. Over the total period of 2 days (Tuesday and Wednesday):
forecast sales = 240 = 80
Expected stock:
Expected stock = 100 + 0 - 80 = 20
1. Calculation of the dynamic target stock
1. Addition of the forecast sales (period: End of the replenishment run time until the end of the target range of coverage)
2. The period taken into account is from Thursday morning of week 21 to Thursday morning of week 21. 40 pieces would be sold a day in week 20, 50 in
week 21. Over the total period of 6 days (Thursday, Friday, Monday, Tuesday and Wednesday):
Forecast sales = 340 + 350 = 270
3. The safety stock of 10 is added.
4. Target stock:
Target stock = 270 + 10 = 280
5. Limitation using minimum and maximum stock levels
A minimum stock level was not specified. The maximum stock level of 500 is not exceeded. The result is therefore not changed.
1. Calculation of replenishment requirements
Replenishment requirement = target stock - expected stock
= 280 - 20
= 260
1.1.3.5.4 Replenishment: Using a Reorder Point
Use
In Replenishment article data, you can define a reorder point. As a result, Replenishment only creates follow-on documents when the stock on-hand or - if you
are including receipts and issues in the calculation - the expected stock has fallen below the reorder point. The reorder point is used as it is in reorder point
planning.
Example
The following example illustrates the effects of using a reorder point in Replenishment. You have defined a reorder point of 10 pieces. The Replenishment run
generates purchase orders as follow-on documents. Store stock refers to the physical stock figure in a store.
Transaction Stocks Target stock Requirement Physical stock
Starting point 100 100 100
Goods issue 80 20 100 20
Replenishment run 20 100 0 20
Goods issue 15 5 100 5
Replenishment run 5 100 95 5
Purchase order created 5 100 5
Goods receipt 95 100 100 100
Use
You can plan replenishments:
manually
in the background
.
You can plan replenishments for sites or customers. If the recipient is a customer, the following constraints apply:
You can only use Replenishment-based Inventory Management. This means planned receipts and issues cannot be taken into account.
Only sales orders are generated as documents following on from replenishment planning.
The following describes how to plan replenishments for sites. Replenishments are planned for customers in the same way, with the above-mentioned
constraints.
Procedure
To plan replenishments for sites manually, proceed as follows:
1. Enter either sites or site groups on the Replenishment: Planning Screen . Limit your selection further by article and merchandise category.
If you want to determine expected receipts at the time of goods receipt, set the indicator for determining Receipts/issues via ATP . Enter a planning date and
a period at which, when elapsed, the goods receipt will be entered. Planned receipts and issues in the site will then be included for this period. If a forecast
was made beforehand for sales, these values are taken into consideration too.
1. Choose Program Execute to obtain a list of replenishment requirements for the selected sites.
2. If you wish to change the quantities, proceed as follows:
Double-click on the quantity. A window appears detailing the stock levels, expected receipts and issues and the resulting replenishment requirements. Change
the replenishment requirements as required.
1. Choose Replenishment requirements Generate follow-on document. The system saves the quantities and generates follow-on documents
(purchase requisitions, purchase orders, deliveries or sales orders).
You can then branch to the Replenishment monitor screen or the parameter overview screen. Here you view the errors, the workitems created and the
generated documents.
Notes and Remarks
If you run the program in the background , this must be scheduled as a job in the system. If the system runs inbound processing of POS data or of recipient
stock and sales data, this must be complete before replenishments can be planned.
With background processing, you can set up technical parameters that divide up the items to be processed in smaller logical units.
1.1.3.6 Replenishment Monitor
Use
You can analyze the results of Replenishment in the Replenishment Monitor. This contains information such as the items that were successfully processed
and those in which errors occurred. You can analyze the cause of the errors for the items in which errors occurred. You identify the replenishment run you want
to analyze by entering the number issued internally by the system.
Prerequisites
When you run replenishment online, you can always go to the monitor. If you want to analyze the results of replenishment runs that took place in the
background or were scheduled as jobs, you must activate updating of replenishment results in Customizing. In the standard configuration, updating is
activated.
Features
In the replenishment monitor, the results are divided into the following categories:
successfully processed
work item generated
errors occurred
Each category contains information on how the items were processed (for every combination of recipient and article).
You can view the possible results of the replenishment run when follow-on documents are generated in test mode. Errors that occurred during the generation of
follow-on documents are also displayed. You cannot go to the follow-on documents directly as the documents have not yet been stored on the database at that
time. After you have checked possible results, you can go from test mode to triggering the posting of the documents in the database.
Note
A number is assigned to every potential follow-on document even when follow-on documents are generated in test mode. The number is taken from the
relevant number range. If you exit test mode without posting documents on the database, their current number levels are increased nonetheless. The
document numbers assigned in test mode are therefore "used" and they can no longer be assigned to other documents.
Activities
The logs of replenishment results that are no longer required can be deleted from the database using program RWRPLDEL (transaction WRDL ). How often
you delete this data should depend on the volume of data in the system.
1.1.4 Multi-Step Replenishment
Use
Multi-step replenishment is a method of supplying stores with merchandise according to demand. Multi-step replenishment is the performance-optimized
variant of replenishment , however, you can only use multi-step replenishment for supplying merchandise to stores. A second difference between
replenishment and multi-step replenishment is that with multi-step replenishment, the determination of requirements calculation data and the generation of
follow-on documents is separate from the actual calculation of requirements.
The entire process of multi-step replenishment is shown in the following:
Multi-step replenishment consists of a program for determining requirements calculation data, a second program for calculating requirements and a third
program for generating follow-on documents.
The program for determining requirements calculation data is used to compile and save the master data required for requirements calculation. Using this
master data, the program for calculating requirements can determine and save requirements according to two MRP procedures or using a combination of these
procedures:
reorder point planning
time-phased planning
a combination of reorder point planning and time-phased planning
Follow-on documents for these requirements (purchase orders, purchase requisitions, sales orders or deliveries) can be generated using the third program for
follow-on documents.
Multi-step replenishment can be carried out using two different procedures.
Two-step procedure
Within multi-step replenishment, the two-step procedure only uses the programs for calculating requirements and generating follow-on documents. The program
for determining requirements calculation data is not used in the two-step procedure.
Three-step procedure
Within multi-step replenishment, the three-step procedure uses all three programs.
Integration
Article (or material)
You can process article-related multi-step replenishment data using article maintenance (in an SAP retailing system) or using material maintenance (in an SAP
manufacturing system).
Site
In the site master you maintain different sets of data for controlling multi-step replenishment. You can, for example, determine the type of follow-on documents
that are created. Note that you can only use multi-step replenishment for stores.
Inventory Management
You can use Inventory Management in Materials Management as the basis for multi-step replenishment.
POS Interface - Inbound
In POS interface inbound processing, sales data is first evaluated and made available to Multi-Step Replenishment. The sales data is not updated to Inventory
Management at goods issues until a second step, carried out at a later point in time. Parallel to the first step, the POS sales data is updated into a separate
database table for the sales forecast.
For more information, see POS Inbound Processing Procedure .
Store Order
A function from the store order is called to generate follow-on documents in multi-step replenishment.
Features
Calculating the requirements for multi-step replenishment using stock data.
Simplified replenishment-based Inventory Management enables you to use replenishment for Inventory Management on a value-only basis.
Simplifyied master data maintenance by grouping sites (only stores) with similar requirements together in requirement groups.
Planned issues and receipts can be taken into consideration based on ATP (available-to-promise).
Sales orders, purchase requisitions, purchase orders or deliveries can be generated as follow -on documents for replenishment planning.
See also:
Background Processing: Multi-Step Replenishment
Replenishment
1.1.4.1 Multi-Step Replenishment: Inventory Management Types
Use
When using the Multi-Step Replenishment application component, you can manage inventory in one of two ways:
Materials Management-based Inventory Management
In this case Replenishment is based on the Inventory Management data from Materials Management of the ERP system. Each goods movement is
recorded in a document. You should use this type of Inventory Management as much as possible. It can, however, only be used for Replenishment if
you manage stocks on an exact article basis (not on a merchandise category basis).
Replenishment-based Inventory Management
You can also use Replenishment-based Inventory Management with Multi-Step Replenishment. You activate replenishment-based Inventory
Management by selecting the indicator in the replenishment article data for the article destined for the relevant store. Note that you can only use multi-
step replenishment for stores.
Replenishment-based Inventory Management allows you to replenish stocks of articles managed in MM-based Inventory Management on a merchandise
category basis (value-only article).
In Inventory Management with Multi-Step Replenishment, inventory is managed in a much simpler way than in Materials Management. The only figure
relevant to Replenishment for a particular article at a particular store is the stock on-hand. No goods movements documents are kept.
The following transactions/events can change replenishment stock:
Posting aggregated business volume data (message category WPUUMS ) or non-aggregated sales documents (message category WPUBON )
at POS inbound.
Generating follow-on documents in a replenishment run and the correction of replenishment stocks using document quantities. You can activate
corrections using document quantities in the replenishment article master data.
You can make manual corrections to the replenishment stock using the parameter overview in Replenishment.
The following table illustrates the differences between the two types of Inventory Management for Multi-Step Replenishment:
Characteristics MM-based Inventory Management Replenishment-based Inventory Management
Number of stock types managed high only one
Materials movements documents created Not available
Calculation of planned issues and receipts using ATP possible not possible
(Available-to-Promise)
Article-based stock data for value-only based Inventory not supported supported
Management
1.1.4.2 Multi-Step Replenishment: Scenarios for Multi Step

Replenishment
The following examples indicate possible uses for Multi-Step Replenishment. The initial situation for every example is outlined and then the way in which
parameters have to be set for Multi-Step Replenishment is represented.
"Standard procedure"
Situation:
Article-based Inventory Management has been activated for stores.
Sales are not forecasted.
Stores can order merchandise themselves.
Replenishment parameters for multi-step replenishment:
You use Materials Management-based Inventory Management; the indicator for Replenishment-based Inventory Management in the article master is,
therefore, not set.
You enter a materials planning indicator in the article master for static target stock.
You take planned issues and receipts into consideration when planning Replenishments.
"Simplified procedure"
Situation:
You carry store stocks at value-only article level; MM-based Inventory Management is not article-based.
You do not execute sales forecasts at article/store level.
Replenishment parameters for multi-step replenishment:
You use MM-based Inventory Management; the indicator for Replenishment-based Inventory Management in the article master is, therefore, set. You
can set the opening balance of the article to zero or enter current stock manually, which has been defined externally, using a physical inventory count,
for example.
You enter a materials planning indicator in the article master for static target stock. You can set the static target stock using the opening balance or a
value calculated outside the system.
1.1.4.3 Multi-Step Replenishment: Master Data
Use
You can maintain data for multi-step replenishment in the article and site masters.
Article master
You can define replenishment parameters and forecast data for multi-step replenishment using article maintenance.
Site master
In the site master, profiles for store orders and POS inbound processing are required for multi-step replenishment. You can also maintain requirement groups in
the site master.
Note that you can only use multi-step replenishment for stores.
1.1.4.3.1 Multi-Step Replenishment: Article Master Data for Sites
Use
The article master data contains various data that is relevant for Multi-Step Replenishment.
Features
Maintenance levels
Recipient level
All data relevant to Multi-Step Replenishment is maintained on this level. This is the most detailed maintenance level for data for Multi-Step Replenishment.
You can maintain parameters in the logistics data of an article for each site.
Note that you can only use Multi-Step Replenishment for stores. You cannot use Multi-Step Replenishment for customers.
Requirement group level
Requirement groups make it easier to maintain data for a large number of recipients (stores only). If you maintain replenishment master data for an article at
requirement group level (via Extras ), the data is copied to the site level, provided you have defined a requirement group in the site master for the
merchandise category, and the article is listed in the site.
Data types
The following data is maintained in article maintenance:
MRP parameters for Multi-Step Replenishment
The following kinds of data belong to the MRP parameters for Multi-Step Replenishment:
RP Type (Set in Customizing)
The RP type must be assigned the RP procedure W and a planning method other than 1 (planned by external system). If the RP type is assigned the
forecast indicator + (compulsory forecast) or * (optional forecast), the system calculates the target stock dynamically in the replenishment planning run. If the
sales forecast is supposed to calculate the reorder point and safety stock automatically, you must set the relevant indicator in Customizing. If you want to
plan using a dynamic target stock, you must have previously forecast the sales. For time-phased planning, the "Plan Regularly" indicator must be set.
The following characteristics are provided in the standard system: RP (replenishment planning with static target stock), RF (replenishment planning with
dynamic target stock) RR (time-phased replenishment planning with dynamic target stock) and RS (time-phased replenishment planning with static target
stock).
Reorder point
If a reorder point is maintained for time-phased replenishment planning (RR or RS), a combination of reorder point planning and time-phased planning is
activated. This means that if the reorder point is not reached outside the cycle, a requirement can be calculated outside the cycle.
Safety stock
Replenishment parameter for multi-step replenishment
Target stock, minimum and maximum target stock, target range of coverage
Replenishment-based Inventory Management indicator ( Replenish.IM)
If you flag the indicator, stocks are determined using Replenishment-based Inventory Management. If you do not flag the indicator, the system calculates
stocks using MM-based Inventory Management.
This indicator only has an effect if Replenishment-based Inventory Management is used. If this indicator is set and replenishment is run, the quantities in
follow-on documents generated are added to the stock figure used for Replenishment and are thus considered as expected goods receipts. It makes sense to
set this indicator if the only information you have as the basis for Replenishment is store sales information.
Availability checks
You must enter a check group for the availability check in the logistics data for articles for which planned receipts and issues are to be included in the planning
run.
Sales forecast
You can enter forecast data (for example, forecast models) in article maintenance for articles with Inventory Management on an exact article basis. The
forecast is based on sales forecast functions.
Block for multi-step replenishment
An article can be blocked for Replenishment by using the following status in the article master:
General article status
You can choose to set this status either on the client level or the site level. If a block is set, an error message is generated in Replenishment planning. You
can determine the influence (for example, on Requirements Planning, Purchasing or Inventory Management) that a particular status may have in Article
Customizing using control data. In order to affect Replenishment, you must set a block for requirements planning at the relevant status in Customizing.
Sales status
You can set this status at client level, for the distribution channel or the distribution channel/site level. If a block is set, an error message appears when
generating follow-on documents. You can determine the influence (for example, on sales orders or deliveries) that a particular status may have in Article
Customizing via sales relevant data. In order to influence Replenishment, you must set a replenishment block in retail-specific article settings for the article
status for Retail functions.
Planning Calendar
For time-phased planning, a planning calendar needs to be maintained for the planning cycle.
1.1.4.3.2 Multi-Step Replenishment: Structured Articles
Use
Replenishment planning with multi-step replenishment allows you to calculate the requirements for a header article of a structured article based on the
requirements for the relevant components. If you run replenishment planning with multi-step replenishment for the components and the components are not
listed individually, the component requirements are converted into a header article requirement.
Integration
The following general function is used to calculate the header article requirements based on the component requirements: Requirements Planning: Calculating
the Header Article Quantities based on the Component Quantities .
Prerequisites
You cannot list components individually for relevant stores but only as components of structured articles. If components are listed individually, they are
also procured individually.
You also have to maintain the replenishment data for each component in the article master.
You must enter a universal availability indicator for multi-step replenishment in the logistics data for header articles and related components.
Example
If you want to maintain the master data for a prepack and run replenishment planning for components, you must follow the sequence listed below:
1. Create a generic article (with variants)
2. Maintain the suitable replenishment data that is to be copied later in the logistics data of the generic article at reference site level.
Enter the availability indicator ND in the logistics data at reference site level so that replenishment planning is not carried out for that article.
3. Create a bill of materials for a prepack, based on the generic article.
4. List the prepack.
Here, the prepack components, in this case the generic article variants, are also listed. In accordance with the default logic of the article master, the
replenishment master data is generated for the components in the listed sites.
1.1.4.3.3 Multi-Step Replenishment: Logistical Variants
Use
When generic articles have logistical variants, the procurement variants can differ from the sales variants. If this is the case, it is the procurement variant that
is used in follow-on documents for replenishment. Replenishment therefore transfers procurement requirements to another variant. If several procurement
variants are assigned to the article, the system selects the ones that are listed for the store concerned.
Prerequisites
1.1.4.3.4 Multi-Step Replenishment: Requirement Groups
Use
When you have to manage a large number of stores or a large number of articles, you can reduce the effort required to maintain the large amount of data by
defining requirement groups. This prevents you from having to maintain all the data for every combination of store and article.
Prerequisites
You can only use requirement groups if you use SAP Retail .
Features
You create requirement groups for every merchandise category. A group comprises all the sites that have the same requirements in a particular merchandise
category and that therefore place the same demands on Replenishment.
You maintain requirement groups as follows:
1. You assign requirement groups to merchandise categories in the site master.
2. You list the articles for which you want to define requirement group values in all the relevant sites.
3. You maintain replenishment parameters in the article master at requirement group level (and not at site level).
If you have to change a parameter for an article for the whole requirement group, you only have to make one change. If a particular article is listed in a site, the
data at requirement group level is copied to site level.
You can maintain values for specific articles at site level that differ from the requirement group values. These values are treated as exceptions and are
protected from being over-written. Some data, such as the RP type, cannot be maintained at requirement group level. This data must be maintained at site
level.
1.1.4.3.5 Multi-Step Replenishment: Example of Use of

Requirement Groups
The following example illustrates how the use of requirement groups affects Multi-Step Replenishment.
Requirement Group Assignment in the Site Master

The following table illustrates several site master records. A requirement group has been assigned to the confectionery merchandise category.
Site Merchandise category Description Requirement group
R153 R1115 Confectionery 02 (medium)
Replenishment Article Data at Requirement Group Level

Replenishment data has been defined at requirement group level for article R100002 (chocolate) in merchandise category R1115 (confectionery):
01 (large) 90 300
02 (medium) 30 120
Replenishment Article Data at Site Level

The system copies the replenishment article data from requirement group level to site level. It does so based on the site group assignments made in the site
master.
R100002 Chocolate R151 90 300
R100002 Chocolate R152 90 300
R100002 Chocolate R153 30 120
Every change made to the replenishment data at requirement group level is automatically copied to the sites. This makes it more convenient to maintain data
when a requirement group contains a very large number of sites.
Replenishment Data at Site Level with Exceptions

Even though site R152 is assigned to a requirement group, you change its reorder point to 80.
R100002 Chocolate R152 80 300
You then change the reorder point for requirement group 01 to 100.
01 (large) 100 300
This change is then made for all the sites assigned to the requirement group. The reorder point for site R152 differs from that of the requirement group. It is
therefore treated as an exception and not changed.
R100002 Chocolate R151 100 300
R100002 Chocolate R152 80 300
R100002 Chocolate R153 30 120
1.1.4.3.6 Multi-Step Replenishment: Site Master Data
Use
The following data for controlling Multi-Step Replenishment can be maintained in the site master. You can, for example, define suggested values for the type
of generated follow-on documents or assign requirement groups to merchandise categories.
Features
In the site master you maintain the following data for controlling Multi-Step Replenishment:
Store order control parameters
Multi-Step Replenishment uses the store order functions to create follow-on documents. You can maintain store order control parameters in a POS inbound
profile in the Customizing section for POS inbound. Profiles are assigned to sites.
You can also enter special profiles for Replenishment and the Store Order which you can then assign in the site master at merchandise category level.
The parameters relevant for Replenishment include:
Default setting for the document category
This controls the follow-on document created, for example, purchase orders or deliveries. You can enter different default values for every type of source of
supply (internal or external vendor). If no details exist, the system uses the general default value.
Default delivery type
If the follow-on document created is a delivery, you can enter a default document type for the delivery.
Error message control
POS inbound processing control
To control POS inbound processing, you assign a POS inbound profile to the site. Depending on the type of Inventory Management used (MM-based or
Replenishment-based), in the Customizing section for POS inbound you must adjust the process control in the POS inbound profile for:
Aggregated sales
Sales as per receipts
If you use MM-based Inventory Management, you must set the Inventory Management (IM) indicator.
You should set the indicator for updating Replenishment-based Inventory Management to "1" when using Multi-Step Replenishment.
Requirement group control parameters per merchandise category
You can assign a requirement group to each merchandise category in every site for Replenishment. The requirement group values for the site are thus copied
to all articles in the merchandise category listed in the site.
Requirements planning indicator
If you want to run replenishments using the net-change method, you must set the Requirements planning indicator in the listing/requirements planning data.
1.1.4.4 Multi-Step Replenishment: Sales Forecast
Use
The system uses forecast data in Replenishment Planning at two points. To be able to use both points, you need to set the forecast indicator for the RP type
to obligatory or optional forecast.
In replenishment planning, you can consider forecasted sales as expected issues. In doing so, sales are considered from the time of planning until the
end of the replenishment lead time.
If you work with dynamic target stock, the system recalculates the target stock in replenishment planning based on forecasted sales data. In this
example, sales are calculated based on the end of the replenishment lead time for the duration of the target range of coverage.
A number of models are available for running a sales forecast (for example, trend models or constant models).
Features
Sales Forecast for Multi-Step Replenishment
Planning methods for multi-step replenishment that use a forecast, only use the sales forecast. Note that you can only use multi-step replenishment for stores.
You maintain the forecast parameters in the article master. You can also select the periods in which the forecast values should be updated, for example, each
day, week or month.
For more information, see Requirements Planning .
Performing the Sales Forecast
You can start the sales forecast using transaction WFCS01. The sales forecast has numerous selection options to enable you to set up target-oriented
forecasts.
In contrast to the forecast in MRP, the sales forecast uses its own data basis for movement data (POS history + sales forecast values). In order to achieve an
optimal distribution of computer capacity and the best possible performance, you can use parallel processing of stores when carrying out the sales forecast.
You can display mainly technical information about the activities performed during the sales forecast run in a log.
Caution
Note that when the reorder point and safety stock are calculated automatically, the fields in table MARC are updated without a database lock being set.
Sales Forecast Monitor

You can display the results of the sales forecast using transaction WFCS03. The movement data and the master data for the individual articles/plants are in
the foreground.
Caution
Note that the movement data from the sales forecast (forecast and consumption data) can be viewed using the sales forecast monitor. It is not visible in
the article master.
Sales Forecast Maintenance

During the course of the sales forecast, lots of data, especially movement data is created. In order to keep the size of the database table down to a minimum
and thus maintain the performance of the system, you should regularly delete obsolete logs from the sales forecast using transaction WFCSL02. You should
also delete movement data for the sales forecast that is no longer valid at regular intervals using transaction WFCS02.
Caution
Note that in order to calculate the forecast, you must leave a sufficient number of periods in the system.
Transferring Legacy Data from Table MVER

If you plan to replace the standard forecast or MRP with the sales forecast, you can carry out a legacy data transfer from table MVER to table WFCS_WRFT
using transaction WFCS04.
Maintain the Forecast consumption indicator in Customizing for Planning Characteristics whilst transferring legacy data.
1.1.4.5 Multi-Step Replenishment: Replenishment Planning
Use
Replenishment planning with multi-step replenishment calculates replenishment requirements and then produces follow-on documents for procurement and
delivery during follow-on document generation. Planning results can be displayed in the replenishment monitor. Using the replenishment monitor, you can see
which follow-on documents have been created and which errors have occurred. You can schedule replenishment planning either online or as a job in the
system. SAP recommends you carry it out as a job in the system.
You can only perform replenishment planning with multi-step replenishment for stores.
Multi-step replenishment can be carried out using two different procedures.
Two-step procedure
Within multi-step replenishment, the three-step procedure uses all three programs.
Prerequisites
If you update stock information for multi-step replenishment using POS inbound processing, the processing must have come to an end before you start
For more information, see POS Inbound Processing Procedure .
Procedure
Determining Requirements Calculation Data
When determining requirements calculation data within the three-step procedure, you can determine the following data beforehand and prepare the
requirements calculation and follow-on documents generation steps.
Determine stock situation
Determine issues and receipts using Available-to-Promise (ATP)
Redetermine the master data
Purchasing processing time per store
General material master data
Logistics data for the material
Redetermine parameters for document generation
Supply source determination
Rounding parameters
Requirements Calculation
1. You can start requirements calculation manually (online) or automatically by scheduling it as a gob (in batch) for selected stores and articles.
2. If a reorder point is maintained, a replenishment requirement will only be determined if the current stock is equal to or falls below the reorder point (see
also Using a Reorder Point ).
3. If Inventory Management for Materials Management is active, planned issues and receipts in the store can be taken into consideration until the end of
the replenishment lead time using ATP (see also Including Expected Issues and Receipts ).
4. The system calculates target stock.
5. Target stock can be calculated using replenishment article data (static target stock) or dynamically when replenishment planning is carried out (dynamic
target stock). You can only work with dynamic target stock if forecast sales data exists (see also Planning Using Dynamic Target Stock ).
6. If forecast data exists in the system, you can take the forecasted sales until the end of the replenishment lead time into consideration (see also: Multi-
Step Replenishment: Sales Forecast ).
7. The system calculates your required replenishment quantity.
8. The required replenishment quantity is the difference between the target stock and the standard stock.
If, in replenishment planning, requirements are determined for components of structured articles, the system converts the requirement to that of the
header article. The header article is then entered in the follow-on documents.
9. Quantity optimizing can be performed.
The replenishment quantity is the requirement quantity after it has been rounded.
1. Result
If no errors occur, requirements are created for replenishment. If any errors do occur, you can check them in the replenishment monitor. Each time you
execute the program for planning replenishments, the system stores the replenishment run under an internal number. This number is used to identify a
transaction when you subsequently analyze the run in the replenishment monitor. For more information, see Using the Replenishment Monitor in Multi-Step
Replenishment .
Generation of Follow-On Documents
1. You can start the generation of follow-on documents manually (online) or automatically by scheduling it as a job (in batch) for selected stores and
articles.
2. Follow-on documents are generated.
The system uses functions for store order processing to generate follow-on documents (see also Store Orders ). You can generate the following documents:
Purchase requisition
Purchase order
Delivery
Sales order
If no site master data exists for a store, a sales order is normally generated (order type TAV ). Quantity optimization can be carried out during the generation
of follow-on documents. The replenishment quantity is the requirement quantity after it has been rounded (see also Quantity Optimizing ).
If you already rounded the requirements at the requirements calculation stage, you should not carry out another quantity rounding when generating follow-on
documents.
1. Result
If no errors occur, follow-on documents are created for replenishment. Each time you execute the program for planning replenishments, the system stores the
replenishment run under an internal number. This number is used to identify a transaction when you subsequently analyze the run in the replenishment
monitor. For more information, see Using the Replenishment Monitor in Multi-Step Replenishment .
Use
The stock situation in a store can change between the replenishment planning being executed and the stock being made available for sale. Receipts and
issues can cause such changes. In replenishment planning, expected issues and receipts can be determined by the system and can be used when calculating
requirements. In doing so, planned receipts and issues as per ATP (Available-to-Promise) and forecast sales can be taken into consideration in the
calculation.
The time period for taking expected receipts and issues into consideration begins on the planning date and ends when the replenishment lead time ends. For
articles with article-based Inventory Management in Materials Management (MM), the replenishment lead time is defined using article master data
(replenishment lead time = purchasing department processing time + planned delivery time + goods receipt processing time). You can also define the relevant
time period in replenishment planning for other articles.
For more information, see: Multi-Step Replenishment: Including Expected Receipts and Issues .
Features
Receipts and Issues Based on ATP
To take planned receipts and issues into consideration, you need to set the corresponding indicator in replenishment planning ( Consider Receipts and
Issues ). If the indicator has been set for an item, an availability check is executed in the store for the article for this item when the "Replenishment Lead
Time" has ended. The available quantity calculated in this way represents the current stock, corrected to include the planned receipts and issues.
Using ATP, purchase requisitions, purchase orders placed with external vendors, stock transport orders, and deliveries for stock transport orders, for example,
are considered as receipts. Deliveries that are not connected with a system document are not included. Reservations or sales requirements, for example, are
considered as receipts.
Planned issues and receipts can only be determined for articles with MM-based Inventory Management. Before you can use the ATP option, you must enter a
check group for availability checks in the logistics data in article maintenance for the relevant article. You can maintain check groups for the availability check
in Customizing for Sales and Distribution. The check rule is defined internally for Replenishment as RP.
For a combination of check rule and check group, determine the ATP scope of check and use this to determine, for example, which documents are to be taken
into consideration as planned receipts. You can also set whether the availability check is executed with or without a replenishment lead time:
Without taking the replenishment lead time into consideration
This setting is included in the standard delivery. This has the advantage that if two replenishment runs are executed in immediate succession for the same
article, requirements are only calculated during the first run. Planned issues (for example, sales orders) can, however, incorrectly increase current
requirements.
Taking the replenishment lead time into consideration
In order that issues planned for the future do not influence current requirements, you can execute the replenishment check so that it takes the replenishment
lead time into consideration. In this case, however, the ATP check confirms that every quantity is available at the end of the replenishment lead time because
the quantity can be procured by that date. Therefore, the ATP check is called for the day before the replenishment lead time ends, using Replenishment.
Issues Based on Forecast Sales
If you have run a forecast of future sales, you can include these values as issues in the calculation. The system takes future sales into account if the forecast
indicator + (compulsory forecast) is assigned to the RP type.
In doing so, sales are considered from the time of planning until the end of the replenishment lead time. In dynamic target stock, however, sales from the end
of the replenishment lead time for the entire range of coverage (normally for the next two goods receipts) are included in the calculation.
In replenishment planning, the system takes sales on a daily basis into account. If you use a different period for forecasting (such as a week or month), the
system calculates average daily sales as follows:
daily sales = sales per period / number of working days per period

The following table shows a replenishment planning run that includes expected receipts and issues. The run results in replenishment requirements for the
current week (week 0).
Week -2 -1 0 (today) 1 2
Target stock 200 200 200 200 200
Actual stock on-hand 160 145 160
Forecast stock 145 135 170 140 150
Expected receipts 55 65 30 60 50
Expected issues 60 50 50 50 50
Replenishment 30 60 50
requirement
How are replenishment requirements determined?

The replenishment requirement for the week is based on the target stock for the week and the forecast stock at the time of the goods receipt. In the example,
a replenishment lead time of two weeks is assumed. The replenishment requirement for the current week is calculated as follows:
Replenishment requirement (week 0) = Target stock (week 0)
- forecast stock (week 2)
= 200 - 150
= 50
How is forecast stock calculated?

The forecast stock for any week in the future is based on the actual stock for the current week and the expected receipts and issues from now until the future
week. In the example, a replenishment lead time of two weeks is assumed. The forecast stock for week 2 is calculated as follows:
Forecast stock (week 2) = Actual stock on-hand (week 0)

= 160 + 30 + 60 - 50 - 50
= 150
1.1.4.5.3 Planning Using Dynamic Target Stock

You are planning replenishments of article R100499 (chocolate) in store R151.
Article master
The following data exists for the article:
Parameter Value This means:
RP type RF Calculate target stock during planning phase
Replenishment lead time 3 days Time required between DC R300 placing PO and store
R151 receiving goods
Target range of coverage 7 days In line with delivery cycle. Deliveries weekly, on
Thursday mornings
Safety stock 10 pieces Stock should not fall below this level.
Maximum target stock 500 pieces Stock should not exceed this level.
Minimum target stock Not stated Stock should not fall below this level.
Current stock 100 pieces Stock level in store R151 on planning date
Forecasts
A forecast is run for the next four weeks for the article. The following values are produced:
Calendar week 20 21 22 23
Sales (in pieces) 240 300 240 240
Replenishment Planning
You plan replenishments on the Monday evening of week 20, taking planned receipts and issues into account. Since there is a replenishment lead time of 3
days, a stock transport order is generated as a follow-on document for the replenishment run. The stock can be delivered from distribution center R300 by
Thursday morning of week 20.
The planning run operates as follows (all quantities in pieces):
1. Calculation of the expected stock
1. The stock currently available (100) is determined.
2. Planned receipts and issues based on ATP are added (period: from planning date to the end of the replenishment lead time).
3. No such transactions are planned between Monday evening and Thursday morning. The value is therefore zero.
4. The forecast sales are subtracted (period: from planning date to the end of the replenishment lead time).
The period taken into account is from Monday evening of week 20 to Thursday morning of week 20. Based on 6 working days a week, 40 pieces would be sold
per day in week 20. Over the total period of 2 days (Tuesday and Wednesday):
forecast sales = 240 = 80
Expected stock:
Expected stock = 100 + 0 - 80 = 20
1. Calculation of the dynamic target stock
1. Forecast sales are added (period: from end of replenishment lead time to end of target range of coverage).
2. The period taken into account is from Thursday morning of week 20 to Thursday morning of week 21. 40 pieces would be sold a day in week 20 and 50
pieces per day in week 21. Over the total period of 6 days (Thursday, Friday, Monday, Tuesday and Wednesday):
Forecast sales = 340 + 350 = 270
3. The safety stock of 10 is added.
4. Target stock:
Target stock = 270 + 10 = 280
5. Limitation using minimum and maximum stock levels
A minimum stock level was not specified. The maximum stock level of 500 is not exceeded. The result is therefore not changed.
1. Calculation of replenishment requirements
Replenishment requirement = target stock - expected stock
= 280 - 20
= 260
1.1.4.5.4 Using a Reorder Point
Use
In Replenishment article data, you can define a reorder point. By doing this, the requirements calculation only calculates replenishment requirements when the
current stock falls below the reorder point.
Example
The following example illustrates the effects of using a reorder point in Replenishment. You have defined a reorder point of 10 pieces.
Transaction Current stock Target stock Replenishment requirement
Starting point 100 100
Goods issue 80 20 100
Replenishment run 20 100 0
Goods issue 15 5 100
Replenishment run 5 100 95
Purchase order created 5 100
Goods receipt 95 100 100
Use
You can plan replenishments:
manually or
in the background
.
You can plan replenishments with Multi-Step Replenishment using two different procedures.
Two-step procedure
Within multi-step replenishment, the three-step procedure uses all three programs (requirements calculation, follow-on document calculation and determination
of the requirements calculation data).
Notes and Remarks
To start replenishment planning in the background , you need to schedule the reports as a job in the system. If the system runs inbound processing of POS
interface data or of stock and sales data for the store, this must be complete before replenishment planning is started.
With background processing, you can set technical parameters, which carry out the processing for follow-on document generation in parallel according to
stores.
See also:
Background Processing: Multi-Step Replenishment
Procedure for POS Inbound Processing
1.1.4.6 Using the Replenishment Monitor in Multi-Step

Replenishment
Use
You can evaluate the results of replenishment planning using the replenishment monitor. You can see, for example, which items have been processed
successfully and where any errors have occurred. You can analyze the cause of the error for any items with errors. Each report in replenishment planning is
assigned a number internally. You can use this number to identify a planning run.
Prerequisites
If you want to evaluate the results of replenishment runs in the monitor, you need to activate the update of replenishment results in Customizing for
Replenishment. Updating is active in the standard system.
Features
The results in the replenishment monitor are divided into the following categories:
Processed successfully (follow-on documents only)
The system only displays follow-on documents that were generated by the report for follow-on document generation. The system does not display the
replenishment requirements.
Workitem generated
Contains errors
Each category contains information on how the items were processed (for every combination of store and article).
Once follow-on documents have been created, you can see the results of the replenishment run in the replenishment monitor. In particular, the errors that
occurred during replenishment planning from all the reports are displayed.
Activities
You can delete logged replenishment results that you no longer require in the system using program RWRPLDEL (transaction WRDL). How often you delete
this data will depend on the volume of data in your system.
1.1.5 Requirements Planning: Special Article Categories
Use
This section explains the special features of the following article categories in connection with requirements planning:
Structured articles
When time-phased planning is active, the system can determine the requirement for the header article of a structured article from the components.
Logistical variants
When a generic article has logistical variants, the procurement variant can differ from the sales variant. Requirements are planned in this case for the
procurement variant, whereby the system determines the requirement on the basis of the forecast values for the sales variant.
Prerequisites
You can only use special article categories if you use SAP Retail .
1.1.5.1 Requirements Planning: Structured Articles
Use
This function allows you to calculate the requirements for a header article of a structured article from the requirements for the components. If time-phased
planning is used for the header article, the system uses the listing conditions for the assigned components to determine whether they have to be procured.
In other cases, the system can forecast demand for the components. The requirement for the header article is calculated on the basis of the requirements for
the components.
Integration
The following general function is used for calculating the header article requirement: Requirements Planning: Calculation of the Quantity Required of Header
Article from the Component Quantities
Prerequisites
The function can only be used for time-phased planning. Enter a RP type for time-phased planning in the logistics data of the header article and of the
components. The header article and the constituent components must have the same RP type.
The header article and the constituent components must have the same period indicator.
For technical reasons, the header article must have consumption values. These are not, however, used in calculating requirements. We therefore
recommend entering a reference article for the header data.
The same number of forecast periods should be maintained for the header article and the components.
1.1.5.1.1 Requirements Planning: Calculation of the Quantity

Required of Header Article from the Component Quantities
Use
This function calculates the quantity required for a header article of a structured article from the quantities required of the constituent components.
You can incorporate your own method of calculation using User Exit WSOS0001 and component EXIT_SAPLWSOS_001. If you do not use your own method
of calculation , the system calculates the quantity required for a header article using the mean value method, as explained in the following example:
Example
A display consists of the following:
Component BOM quantity
Component 1 10
Component 2 20
Component 3 30
The consumption figures for the components are as follows:
Component Consumption
Component 1 90
Component 2 160
Component 3 210
For every component, a certain number of displays are required to replace the quantity consumed. This number is the consumption figures for each component
divided by the quantity of each individual component in the bill of material of the structured article.
Component Consumption BOM quantity Required Displays
Component 1 90 10 90 / 10 = 9
Component 2 160 20 160 / 20 = 8
Component 3 210 30 210 / 30 = 7
The mean value of all the components is taken as the number of displays required:
Mean value for the number of displays required = (9 + 8 + 7) / 3 = 24 / 3 = 8
If decimal places appear in the calculation, the system rounds down under 0.5, otherwise it rounds up.
Integration
This function is used in the following areas:
Requirements planning
in time-phased planning of components of a structured article
Replenishment
in the planning of replenishments for components of a structured article
Allocation
in allocations using replenishment allocation strategies where structured articles are involved.
1.1.5.2 Requirements Planning: Logistical Variants
Use
When a generic article has logistical variants, the procurement variant can differ from the sales variant. When this is the case, you run a forecast for the sales
variant only, but not for the procurement variant. Requirements are also planned for the procurement variant only. The system determines the requirement for
the procurement variant on the basis of the forecast values for the sales variant.
Prerequisites
You can only use this function if time-phased planning is active. You must enter the same RP type for time-phased planning in the logistics data of all
the logistical variants of the generic article.
All the logistical variants of the generic article must have the same period indicator.
The same number of forecast periods should be maintained for all logistical variants of the generic article.
For technical reasons, the procurement variant must have consumption values. These are not, however, used for calculating requirements. We therefore
recommend entering a reference article for the procurement variant.
Example
The following variants exist of a generic article:
Sales variant: "Piece"
Procurement variant: "Carton" (= 100 pieces)
Requirements are planned as follows:
1. A forecast is run for the sales variant
Consumption figures for the last periods (in pieces) were: 185, 190, 195, 190. A forecast is run for the variant "piece". On the basis of the consumption
figures, the forecast requirement for the next period is 190 pieces.
2. Requirements are planned for the procurement variant
Requirements are planned for the variant "carton". The system uses the forecast requirement for the variant "piece". The requirement (190 pieces) is
rounded off to multiples of the procurement variant "carton". This results in a requirement of two cartons (i.e. 200 pieces).
1.2 Ordering
Purpose
In Ordering, you procure merchandise to cover the requirements for your stores, distribution centers and customers. These requirements were either entered
manually by you or were determined automatically by the requirements planning, store order, promotion, and sales order functions in the system. The
requirements exist in the system either in the form of purchase requisitions or as purchase orders, for which you have to enter details such as the vendor or
the delivery date.
You procure the merchandise in one or more steps. You can place a purchase order with an external vendor, your own distribution center or in certain
circumstances a store. Stock transfers within your company and return deliveries are handled in purchase orders.
Integration
In SAPRetail, purchase orders are generated by Requirements Planning. They are also generated as documents that follow on from store orders or the
Replenishment process. They can be entered manually or generated automatically from purchase requisitions.
The purchase orders created can be used as a basis for processing subsequent goods receipts, for Invoice Verification and for Subsequent Settlement.
Features
Ordering includes a number of functions to help you create, optimize, and monitor purchase orders.
You use purchase requisitions to manually enter requirements. Purchase requisitions can also be created indirectly by other components in the ERP
system.
See also: MM - Purchasing: Purchase Requisitions
The source of supply can be determined automatically by the system.
See also: Supply Source Determination
Request for quotation (RFQ) management enables you to obtain quotations from a number of different vendors and select the most favorable one.
Existing outline agreements (scheduling agreements and contracts) are also taken into consideration.
See also: MM - Purchasing: Request for Quotation (RFQ) and Quotations
To make sure that the most efficient and economic purchase order is created, the system firstly determines an optimized order quantity. It does this by
using certain rules to round off the order quantity to full packs or the purchase order off to full loads.
See also: Order Optimizing
You can create purchase orders referencing other documents in the system (for example, agreements, purchase requisitions or requests for quotations).
Refer to:
MM - Purchasing: Purchase Orders
MM - Purchasing: Outline Purchase Agreements with Vendors
You can define that, for example, depending on the value of the goods on order or the merchandise category concerned, a purchase order can only be
placed if it is approved (and released) by a particular employee. You can adapt the approval and release procedure to suit your own requirements.
MM - Purchasing: Release (Approval) Procedures
Analysis, printing, and other functions enable you to keep a tight rein on the delivery dates of all your purchase orders right up to final delivery.
Refer to:
MM - Purchasing: E ntering Text, Printing and Transmitting Documents
MM - Purchasing: Reporting in Purchasing
MM - Purchasing: Conditions and Price Determination
MM - Purchasing: Procurement Using Vendor Confirmations
MM - Purchasing: Further Functions
See also:
Store Order
Background Processing: Ordering
1.2.1 Supply Source Determination
Purpose
The supply source determination function is used to assign sources of supply to requirements. This takes account of both internal sources of supply
(distribution centers) and external sources of supply (external vendors).
The System uses source determination, for example, in Requirements Planning, Ordering, Allocation and Store Order functions. Each application can control
how the supply source determination proceeds and analyze the results differently.
Prerequisites
By using the supply source indicator in the article master logistics data, you can define whether it is preferable for the system to search for an internal or an
external source of supply. Supply sources can be defined in the system as follows:
Supplying sites in the site master
You can define internal supply sources by entering one or more supplying sites in the site master data. You have the option of assigning the supplying sites to
sites at the merchandise category level or to entire assortments.
You can enter a validity period and a priority for each supplying site. Priorities enable you to select a supplying site if various valid supplying sites exist for a
particular period.
Purchasing information record
Purchasing information records define internal or external sources of supply.
Outline agreements
The system evaluates the outline agreements that exist in the system when determining supply sources. An outline agreement can be related to an external
source of supply (for example, value contracts) or an internal source of supply (for example, stock transport scheduling agreement). Outline arrangements with
suppliers can be viewed via the purchasing information record, even if outline agreements do not exist.
Quotas
Quotas are used very rarely in retail. Quotas can be used to define various internal or external sources of supply to which procured merchandise is to be
distributed using quotas. You can also enter outline agreements as sources of supply. You can use quotas, for example, that cannot be supplied by a sole
vendor because demand is too great.
Note
If relevant quota arrangements exist, the system checks in Customizing if the quantity required has to be split among different sources of supply (quota
arrangement split). The quantity required is then split up among several supply sources in line with the quota arrangements.
Source lists
Source lists are used very rarely in retail. You can assign internal or external sources of supply, including validity periods, to a combination of articles or sites.
You can also enter outline agreements as sources of supply. You can use source lists, for example, as a fine-tuned control for determining sources for
particular articles.
Process Flow
The system proceeds as follows:
1. Evaluate quota arrangements
2. Refer to Source Determination: Evaluating Quota Arrangements
3. Evaluate source lists
4. Refer to Source Determination: Evaluating Source Lists
5. Evaluate search sequences in the article master
Refer to: Source Determination: Finding External or Internal Sources of Supply
Determine external sources of supply
Determine internal sources of supply
As soon as the system has found at least one valid source of supply, it ends the search and uses the source of supply it found as the search result.
If you carry out source determination online and the system finds more than one possible source of supply, you will receive a window containing the system
suggestions. You can only select one source of supply.
If you carry out supply source determination in the background, the system must determine a clear source of supply so that the system can then generate a
purchase order automatically.
See also:
MM - Purchasing: Determining Sources (Here, step 3 is different from the process in SAP Retail)
MM - Purchasing: Purchasing Information Records
1.2.1.1 Supply Source Determination: Evaluating Quota

Arrangements
Use
A quota arrangement enables purchase orders to be split up among different sources of supply (internal and external) according to a preset ratio. If a valid
quota arrangement exists. the system uses the quotas arranged for the vendors to determine the vendor from which to procure the goods and proposes the
source of supply.
Refer to MM - Purchasing: Quota Arrangements
Features
The following cases can exist:
The system finds a quota arrangement for an external or internal vendor (distribution center)
The system checks if the source of supply is valid. For example, the source of supply must be defined for the period concerned and purchase price conditions
must exist. If the source of supply has been maintained in the source list, the system only takes it into consideration if it is not blocked.
If valid outline agreements exist for a vendor:
An outline agreement or a number of outline agreements are determined as the source of supply.
If no valid outline agreements exist for a vendor:
The internal or external vendor is determined as the source of supply.
No valid entry found
If the system does not find any valid entries in quota arrangements, it continues its search in the source list.
1.2.1.2 Supply Source Determination: Evaluating the Source List
Use
In the source list, you enter the sources of supply that are valid for a particular article over a particular period. These can be fixed vendors or outline
agreements (contracts or scheduling agreements).
You can also flag a preferred source of supply for a particular article as being fixed. The system then always suggests this source of supply even if other
sources are available.
Refer to MM - Purchasing: Source List
Features
Only one valid entry in the source list is found
The vendor or outline agreement is determined as the source of supply
More than one valid entry is found
More than one valid entry in the source list is found. The system proceeds in the same way as when no valid entry is found.
No valid entry found
The system continues its search as determined in the Source of supply field in the article master.
1.2.1.3 Supply Source Determination: Finding External or Internal

Sources of Supply
Use
You can narrow down the search for supply sources for a particular article to internal or external sources of supply and define the sequence in which the
system should search:
The system searches exclusively for an external source of supply (standard).
The system searches exclusively for an internal source of supply (stock transfer).
The system first looks for an external and then for an internal vendor (standard and then stock transfer).
The system first looks for an internal and then for an external vendor (stock transfer and then standard).
To determine the sequence in which it should search, the system evaluated the Source of suppl y field in the logistics data of the article master.
Note
If the site to be supplied with merchandise has been assigned to a supply region, the system only selects a potential source of supply if the source is valid
for the supply region of the site.
Features
Finding External Supply Sources
In this case, the vendor searches for an external vendor. The following cases can exist:
Only one valid outline agreement is found
The outline agreement is determined as the source of supply.
Several valid outline agreements are found
Since the result is not unique, all outline agreements are possible sources of supply. The system then searches for a purchasing information record for the
vendor.
Only one valid purchasing information record is found
The vendor concerned is determined as the source of supply.
Several valid purchasing information records are found
The regular vendor indicator has been set in one of the purchasing information records
The vendor concerned is determined as the source of supply.
The regular vendor indicator has not been set in any of the purchasing information records
More than one valid entry is found The system proceeds in the same way as when no valid entry is found.
No external source of supply is found
Depending on the contents of the Source of supply field in the article master, the system either stops searching or continues searching for an internal source.
If the system finds more than one supply source, outline agreements have priority over information records.
If the system finds two outline agreements, it checks if any of them are with regular vendors. If there is an agreement with a regular vendor, it assigns the
outline agreement as the unique source of supply. If there is no agreement with a regular vendor, then no source is found in this step.
Finding Internal Supply Sources
In this case, the vendor searches for an internal vendor, such as a distribution center.
The system first searches for a stock transport scheduling agreement, then for a supplying site at merchandise category level and finally for a supplying site
for the whole assortment.
If the procurement suggestion was generated via a store order, the system can also perform a sourcing check. If the supplying site found does not have
enough stock, for example, or the maximum delivery quantity is exceeded, the system searches for a different internal source. If no internal source of supply
is found, the system searches for an external source of supply.
One valid stock transport scheduling agreement exists
The agreement is determined as the source of supply.
Several valid stock transport scheduling agreements exist
Since the result is not unique, all agreements are possible sources of supply.
A distribution center has been entered for a site and merchandise category in the site master
The DC is determined as the source of supply. This only applies to the merchandise category of the article to be procured.
A distribution center has been entered for a site in the site master
The DC is determined as the source of supply. This applies to all merchandise categories unless a different entry is found.
No internal source of supply is found
Depending on the contents of the Source of supply field in the article master, the system either stops searching or continues searching for an external
source.
See also:
MM - Purchasing: Purchasing Information Records
1.2.1.4 Supply Source Determination: Requests for Quotations

(RFQs) and Quotations
Use
Retailers usually have long-standing relationships with fixed vendors. However, in certain cases, for example high-value and special articles, it may be
advisable to determine the best vendor using a request for quotation (RFQ) and quotation procedures.
Features
RFQs can be created automatically for a number of vendors from purchase order requisitions, or can be created manually. The quotations received, including
the prices and conditions for the articles concerned, are entered in the related RFQs. The RFQ and quotation therefore form a single unit.
You can use a price comparison list to compare the quotations and determine the best quotation. The data obtained in this way can be automatically saved in
a purchasing info record for the vendor.
1.2.2 Order Optimizing
Purpose
In Order Optimizing, the system combines the quantities in open purchase requisitions and purchase orders and rounds off the total quantity. This enables you
to make best possible use of the transport capacity available.
Process Flow
In SAP Retail, the following activities usually occur in sequence during the night:
1. Forecasts
2. See LO – Sales and Operations Planning : Forecasts in SOP
3. Planning run determining net requirements
4. See Requirements Planning
5. Investment Buying
6. See Investment Buying
The system uses the greater of the two quantities determined in steps 2 and 3.
7. Automatic PO-based load building with quantity optimizing
8. See Automatic Load Building
See Quantity Optimizing
9. Conversion of purchase requisitions to purchase orders with quantity optimizing
See MM - Purchasing Automatic Generation of Purchase Orders from Purchase Requisitions
See Quantity Optimizing
You then evaluate the results of automatic load building using a results list and if necessary build loads manually.
See List of Results of Automatic Load Building
See Manual Load Building
Results
The system generates the relevant purchase orders and adjusts the relevant documents.
1.2.2.1 Quantity Optimizing
Use
When you enter purchase orders, sales orders and deliveries, you can have the system optimize the quantities to ensure that in agreements with customers or
vendors threshold values or the use of complete logistical units of measure, such as whole pallets, can, for example, be guaranteed.
Integration
Quantities are optimized in the following areas (also note the constraints in the Features section).
Purchase orders
Allocation tables
Sales orders
Delivery
Store orders
Consumption-based planning (MRP)
Features
Types of Quantity Optimizing

The quantity optimizing function rounds off quantities you enter according to rules that are predefined in Customizing. You can round either up or down. The
system can also take different units of measure of an article into account. The following options exist:
Rounding off using a rounding profile
You can enter a profile in Customizing. The system will then use this profile to round quantities. If a rounding profile is entered in purchasing or sales
master data, the system rounds off quantities when documents are processed.
Rounding to a multiple by specifying standard quantities in the purchasing info record
This type of rounding ensures that only the valid number of decimal points and permitted logistical units of measure are used.
Checking for threshold value compliance
You can enter fixed values for rounding off items in purchasing and sales master data. The quantity optimizing function ensures that the quantity
rounded to does not fall short of the minimum threshold quantity or exceed the maximum threshold quantity.
Integration with Applications and Restrictions

Purchase orders
Optimum document calculation is available for documents entered online or generated automatically in the background.
Constraints:
The maximum quantity is only taken into account in additional planning.
Collective purchase orders can only be generated online.
Allocation tables
Quantities are optimized at site level for each allocation table item. When quantities are optimized in allocation tables, quantities are not optimized again
when follow-on documents are generated.
Sales orders
Constraints:
Quantities are not optimized for:
Sub-items representing an inclusive or exclusive quantity (such as free goods)
Materials marked for active ingredient management or steel processing
Configurable articles
Generic articles
Orders with the type Scheduling agreement with release (type LZ )
Delivery
Constraints:
The minimum delivery quantity is only taken into account for sales order deliveries.
The maximum delivery quantity and dynamic rounding profiles are only taken into account if the deliveries are generated with a store order.
Store orders
Optimizing is included in store order processing and can be used for all purchase orders, deliveries and sales orders that are generated with a store
order.
Consumption-based planning (MRP)
Quantities are only optimized in purchase requisitions generated as part of a requirements planning run scheduled in the background.
Constraints:
Consumption-based planning only takes static rounding profiles into account. Dynamic rounding profiles and profiles for rounding up and down are not
taken into account.
See also:
Ordering
Allocation
Sales Order Processing
Store Order
1.2.2.1.1 Master Data and Customizing for Quantity Optimizing
Use
In Customizing, you can enter information in purchasing and sales master data to control the optimizing function.
Prerequisites
If you want to use rounding profiles to control the optimization process, you must define them in Customizing for Logistics - General , under Quantity
Optimization . The rounding profiles are then assigned to articles using master data maintenance. The following cases can exist:
Rounding profiles for quantity addition or subtraction
In this case, all the data required for the rounding (threshold values and the quantity percentages to be added or subtracted). For further information, see
Quantity Addition and Subtraction .
Static rounding profile
In this case, all the data required for the rounding (threshold values and rounding values). For more information, see Static Rounding Profiles .
Dynamic rounding profile
In this case, only some of the data required for the rounding is defined in the rounding profile (in particular, the rounding rule to be used). The following
settings are also required:
Rounding rule
The rounding rule determines the threshold values at which the system should round a quantity up or down, and the unit of measure to be used.
Unit of measure group
Unit of measure groups are assigned to the articles in the master data. You specify which units of measure are permitted for dynamic rounding.
For more information, see Dynamic Rounding Profile .
Features
Purchasing
When processing articles or purchasing info records, you define the following:
Order unit
Minimum quantity ( Minimum Quantity field)
Maximum quantity ( Maximum Quantity field)
Rounding profile ( Rounding Profile field)
Unit of measure group ( Unit of Measure Group field)
Variable unit of measure
This data is always maintained for each article, purchasing organization and vendor. At purchasing organization level, the information is valid for all sites, or
only for one site if different data exists for the sites.
Sales
You have the following control options:
Customer master
You can deactivate rounding at customer level for each distribution chain by deselecting an indicator.
Item category in Customizing
In Customizing for sales documents, you use an indicator for each item category to switch the rounding function on or off.
Article master / customer-article information
Minimum quantity ( Minimum Order Quantity or Minimum Delivery Quantity field)
Maximum quantity ( Max. Delivery Quantity field)
Delivery unit (two Delivery Unit fields )
The delivery unit comprises an increment and a unit of measure. If you define an increment, the system rounds off the delivery quantity so that it
can be divided into whole numbers by the increment.
You only have to enter a unit of measure for the increment if the unit of measure is not the base unit of measure. Otherwise, the increment refers
to the base unit of measure.
Rounding profile ( Rounding Profile field)
Unit of measure group ( Unit of Measure Group field)
Variable sales unit of measure
This data is always maintained for each article, sales organization and distribution channel. It can be made customer-specific through the creation of
customer-article information.
1.2.2.1.2 Static Rounding Profiles
Use
Static rounding profiles are used when you want to round up to a multiple of a unit of measure without changing the unit of measure. However, static rounding
profiles can only be used to round up rather than round down quantities.
If you want to have the system round up and down, depending on the quantity, and even have it change the unit of measure where possible, you have to use
dynamic rounding profiles. For more information, see Dynamic Rounding Profiles .
Prerequisites
You must define a rounding profile in Customizing. For more information, see Master Data and Customizing for Quantity Optimizing .
Features
A static rounding profile comprises threshold and rounding values, whereby every threshold value is assigned a rounding value. In rounding off, the system
starts with the highest level in the rounding profile. It processes all the levels below that, carrying out the calculation until the procedure is stopped or until the
lowest level is reached. The lowest level is processed differently, as the rounding logic is different here than in the other levels.
The steps in the procedure are as follows:
As long as the lowest level has not been reached:
It divides the quantity required into whole numbers by the rounding value of the current level.
It then checks whether the remainder is equal to or greater than the threshold value of the current level.
If yes:
It rounds up the quantity required to the next multiple of the rounding value of the current level and stops there.
If no:
It repeats the procedure with the next lower level.
If the lowest level has been reached:
It checks whether the quantity required is equal to or greater than the threshold value of the lowest level.
If yes:
It rounds up the quantity required to the next multiple of the rounding value of the first level and stops there.
If no:
It does not change the quantity required and stops there.
Example
Starting point
The base unit of measure for an article is kilogram, and for small quantities under 2 kg should not be rounded up or down. Quantities greater than 2kg should
be rounded up to units of 100kg if rounding accounts for less than 200 kg.
Relevant static rounding profiles

The following static rounding profile covers the requirements above
Level Threshold values Rounding value
1 2 100
2 301 500
Effect of the rounding profile (for quantities of 1 to 1000)

The following table illustrates how the static rounding profile creates quantity intervals from 1 to 1000. These intervals each have a particular value to which
quantities are rounded off.
Quantity from To Rounded quantity
1 1 1
1,5 1,5 1,5
3 100 100
101 200 200
201 300 300
301 500 500
501 600 600
601 700 700
701 799 800
801 1000 1000
Rounding procedure for a quantity of 2215 kilograms

With a quantity of 2215 kilograms , the procedure would be as follows:
1. The system would start at level 2, dividing the requirement quantity of 2215 by 500 (the rounding value for level 2).
2. The result is 4, with the remainder of 215 being smaller than 300 (the threshold value for level 2), so the system proceeds to the next smallest level
(level 1).
3. The lowest level is level 1. The requirement quantity of 2215 is larger than 3 (threshold value of level 1), so the system rounds up the quantity to 2300.
1.2.2.1.3 Quantity Addition and Subtraction
Use
Quantity addition and subtraction is a method of rounding off quantities. It works in a similar way to static rounding in that quantities are rounded off
independently of units of measure. It is used for rounding off quantities of additionals, but can also be used in other applications.
Prerequisites
You must define a rounding profile in Customizing. For further information, see Master Data and Customizing for Quantity Optimizing .
Features
You can maintain the percentages you want to add or subtract in an addition/subtraction profile for various threshold values (quantities).
If a quantity is entered that is the same or greater than the threshold value, the system either adds or subtracts the specific percentage and thus rounds off
the quantity.
Example
You need to order 100 suits. The article Suit has 2 additionals assigned to it - Ticket and Hanger . When they have been delivered, you want the two
additionals to be attached to the suit. To account for wastage or wrong use, you need 15% more tickets and 10% more hangers than suits.
To make sure that all 100 suits have tickets and hangers, you want the system to include the extra quantities required in the purchase order. It does this by
using the percentages that have to be added on.
The system can determine the percentages from additional/subtraction profiles as long as you have created the following two rounding profiles and assigned
them to the additionals.
Add1 (for the hangers):
Threshold value 1
Addition/subtraction (%) 10
Add
Add2 (for the tickets):
Threshold value 1
Addition/subtraction (%) 15
Add
The system automatically suggests that you order the quantity of additionals that results from adding on the percentage valid for the threshold value.
1.2.2.1.4 Dynamic Rounding Profile
Use
You use dynamic rounding profiles to round to multiples of a unit of measure, thereby changing the unit of measure. Dynamic rounding profiles are highly
suited for rounding to complete logistical units of measure (such as whole pallets).
Prerequisites
In Customizing, you must define a rounding profile, a rounding rule, and a unit of measure group. For more information, see Master Data and Customizing for
Quantity Optimizing .
Features
In Customizing, you define how dynamic rounding takes place, by defining a dynamic rounding profile, a rounding rule, and a unit of measure group. Rounding
profiles and unit of measure groups are then assigned to the articles using master data maintenance.
Dynamic Rounding Profile
A dynamic rounding profile consists of a rounding rule and a rounding method.
Rounding method
The rounding method controls how rounding is performed. The rounding methods that are possible are predefined in the system. The following are examples of
possible rounding methods:
Rounding to a multiple of the order/sales unit without a change in the unit of measure.
Rounding to a multiple of the order/sales unit with a possible change to the unit of measure (for example, to larger units, such as pallets).
Rounding rule
The rounding rule consists of units of measure and percentage threshold values. You can define your own rounding rules in Customizing. You do this by
assigning a threshold value at which the system rounds up or down, to each unit of measure. The rules for conversion between the different units of measure
must be defined in the relevant article master.
The unit of measure group specifies which units of measure are allowed for the vendor or the recipient of the goods. The units of measure to be used in
rounding are derived from the rounding rule and the units of measure to be used for the article. If you wish to round to a specific unit of measure, the system
performs the following checks based on the settings in the rounding profile:
Is the unit of measure contained in the unit of measure group for the article from the vendor?
Is the unit of measure contained in the unit of measure group for the article from the distribution chain?
Example
Starting point
An article can be ordered in boxes, layers or pallets. In purchase orders, the system should round to the unit of measure most suitable for logistics purposes.
Settings in Customizing
Rounding Rule for the Dynamic Rounding Profile

You first define rounding rule 01 for later use in a dynamic rounding profile.
Rounding rule Unit of measure Round up (%) Round down (%)
01 Box 50 < Not allowed
01 Layer 70 < Not allowed
01 Pallet 90 < Not allowed
Dynamic Rounding Profile
For this example you define rounding profile 0001 with the following main parameters:
Rounding method 2
Rounding to a multiple of the order/sales units of measure with a possible change to the unit of measure.
Rounding method 01

You use unit of measure group 0010 which contains the units piece, box, layer and pallet.
Unit of measure group Unit of measure Description
0010 PC Piece
0010 BOX Box
0010 LAY Layer
0010 PAL Pallet
Data in the Article Master
Rounding profile
You assign rounding profile 0001 to the article in the logistics data.

You assign unit of measure group 0010 to the article in the logistics data.
Units of measure of the article

The article uses piece as the base unit of measure. In addition, you assign the following alternative units of measure to the article in the basic data:
Alternative unit of measure Conversion to base unit of measure
Box 10 pieces
Layer 100 pieces
Pallet 500 pieces
Example: Rounding procedure for a quantity of 425 pieces

You order 425 pieces of an article.
The system determines the order quantity by checking the criteria in the rounding rule (see above), from top to bottom, as follows:
The system checks if a whole pallet can be ordered (500 pieces). According to the rounding rule, a pallet can be ordered if it is 90% full (450%). A pallet can
therefore not be ordered.
The system checks if layers can be ordered. To cover the quantity required, 5 layers (500 pieces) would have to be ordered. According to the rounding rule, a
pallet can be ordered if it is at least 70% full (70 pieces). At least 470 pieces would therefore have to be ordered, ruling out ordering in layers.
The system checks if boxes can be ordered. To cover the quantity required, 43 boxes (430 pieces) would have to be ordered. According to the rounding rule,
rounding can be performed if the last box is, at least, 50% full (5 pieces). The order quantity would therefore have to amount to at least 425 pieces, which is
the case here.
Result: The order quantity will be rounded to 43 boxes (430 pieces).
1.2.2.1.5 Threshold Value Check in Quantity Optimizing
Use
You use the threshold value check to optimize order quantities. In purchasing, this check is only made in additional planning.
Features
The system only checks the threshold values after it has analyzed the rounding profile. If a rounding profile is available and the quantity has been rounded off,
the new quantity may have to be changed again.
If you have defined threshold values for a quantity, the quantity cannot exceed/fall short of these values. So the system rounds off once again to the minimum
or maximum quantity.
Example
You place an order for distribution center “North” of 425 pieces of article 500004711 with vendor “Jones.”
When the system optimizes the quantity using the dynamic rounding profile, it calculates an order of 43 boxes containing 10 pieces each.
In the purchasing information record for “Jones,” article 5000004711 and distribution center “North,” the minimum quantity is 50 boxes.
The system therefore rounds the order item, in this case to the minimum quantity of 50 boxes.
1.2.2.1.6 Quantity Comparison for Schedule Lines in Sales Orders
Use
If, when you are creating or changing a sales order item, you define schedule lines and the item concerned is relevant for quantity optimizing, the system
optimizes at schedule line level. To prevent the sum of the rounded schedule line quantities deviating greatly from the total order quantity for the item as a
result of rounding, the system carries out a quantity comparison for the schedule line quantities.
Features
The system compares the schedule lines in the sequence of planned delivery dates. If the system rounds up a schedule line quantity, an overdelivery quantity
is created. In the next schedule line, the system calculates the difference between the current order quantity of the schedule line and the overdelivery quantity
from the previous schedule line and distinguishes between the following cases:
The difference is greater than zero
In this case a delivery must be created. The system determines the current quantity to be delivered by rounding the current order quantity.
The difference is smaller or equal to zero
In this case, the current order quantity is already covered by the overdelivery from the previous schedule line, and the system sets the quantity to be
delivered to zero.
The system then calculates the over-delivery quantity for the current schedule line using the following rule in both cases :
Current overdelivery quantity =
previous overdelivery quantity
+current quantity to be delivered
– current order quantity
1.2.2.1.6.1 Example of Quantity Comparison in Quantity

Optimizing
A number of schedule lines are maintained for a sales order item. An order quantity is entered in pieces for each schedule line. A box contains 100 pieces.
The following rounding rule exists for converting pieces to boxes:
Round down if under 10%
Round 10% or over
The following table shows the schedule lines and illustrates how the quantities would be rounded if no quantity comparison took place.
Delivery Date of Schedule Line Order Quantity Rounded Quantity
01.01. 60 pieces 1 box
01.02. 10 pieces 0 boxes
In this case, a total of 400 pieces (4 boxes) would be delivered. If, as a comparison, you were to use the rounding rule on the quantity actually required for 240
pieces, this would result in a rounded quantity of 300 pieces (3 boxes), that is, 100 pieces fewer.
The following table shows, again as a comparison, the schedule lines and illustrates how the quantities would be rounded if quantity comparison does take
place.
Delivery Date of Schedule Line Order Quantity Overdelivery Quantity Rounded Quantity
01.01. 60 pieces 40 pieces 1 box
01.02. 10 pieces 30 pieces 0 boxes
01.04. 80 pieces 0 boxes
No delivery is necessary on April 1 because the overdelivery quantity of March 1 already covers the order quantity of April 1. Instead of the 240 pieces
required, in this case 300 pieces (3 boxes) would be delivered.
1.2.2.2 Investment Buying
Use
Investment Buying helps you decide whether you could best cover future requirements by purchasing articles now that are due to increase in price. The
purpose of investment buying is to buy efficient quantities of suitable articles just before the price goes up.
To determine the best possible quantity to buy, the system compares the current stock on-hand, the forecast requirements and the cost of ordering,
transporting and storing the goods in a calculation based on return on investment (ROI). The system works out whether it is worthwhile procuring articles
before they are actually required, and, if so, when and how much to procure. If the return-on-investment is greater than the calculated risk set in Customizing,
SAP Retail automatically includes the quantity in the purchase order.
Integration
Investment buying is integrated with the following areas:
Purchasing
Purchase requisitions or purchase orders can be generated as a result of Investment Buying.
Workflow
Before follow-on documents are generated, you can have the system generate work items. The work items are processed by the staff and converted to
purchase requisitions or purchase orders. You can configure workflow so that the system sends the work items to the inbox of the relevant staff member.
Load Building
Investment buying can be included in load building
Prerequisites
Before you can use investment buying, you must have the authorization for creating a purchase order or purchase requisition.
You must define the relevant purchase price condition types in Customizing. When these condition types change, this is taken into account in
investment buying and can trigger procurement.
Before you can determine requirements, you have to run report RMEBEIN4 to determine all the relevant condition changes for the required period. This
report generates condition change pointers that are analyzed during requirements determination.
See also:
Automatic Updating of Documents Following Condition Changes
1.2.2.2.1 Requirements Determination Procedure for Investment

Buying
Use
The system uses the requirements determination function to find out which articles can be considered for investment buying during a particular period.
Procedure
You can calculate requirements in two different ways:
In the background
Usually the system has to process a large amount of data, making background processing the better option. You define how often the report is run, for
example daily. You have various options for narrowing down and controlling your selection.
Online
It only makes sense to run the report online if you narrow down the data to be processed to an absolute minimum. You would do this, for example, to
determine requirements for an individual article.
Requirements are determined and follow-on documents generated directly afterwards in the following sequence:
1. Program RMEBEIN4 determines all relevant condition changes for the desired period. If you do not use direct creation of worklist entries , you can
specify in Customizing that it should also write condition change pointers.
2. If any relevant purchasing conditions have changed, the system determines the order price on the date of the change for the articles concerned, and
calculates the return on investment to decide whether forward-buying would make economic sense.
3. If forward-buying makes sense, the system generates follow-on documents in line with the control parameters.
You have the following control options:
Limiting selection
You can narrow down the amount of data analyzed by entering selection values, such as a particular vendor, article or site.
General control parameters
You can control which type of follow-on document is generated and whether the vendor with the most favorable conditions is always selected.
Result
The requirements determination run results in a log being generated. You can evaluate this log using the analysis function. This shows how the stock situation
will develop in the weeks and months to come if you make use of forward-buying and helps you decide whether buying would be a good investment.
1.2.2.2.2 Analysis Functions in Investment Buying

You can use the following analysis functions for investment buying:
Subsequent analysis
This allows you to determine which articles were actually bought and which are still in storage. The following information is available:
List of follow-on documents generated
Stock overview
List of all goods movements for an article
Purchase price simulation
You can simulate generation of a purchase order for a vendor and article. This allows you to determine the exact purchase price conditions without
actually entering a purchase order.
Return on investment (ROI) analysis
Based on an article, vendor, previous price and future price, you can decide whether it would be best to buy more stock in view of price changes and
what to articles to buy. The system automatically makes the same calculation when determining requirements.
1.2.2.3 Load Building
Use
Load building is used to:
Minimize transport costs by making best possible use of the means of transport (for example, ship, rail freight container, truck)
Minimize the merchandise in the warehouse by placing a purchase order at the latest possible moment.
Achieve the best purchase prices, for example, by ordering complete truck loads.
To this end, if possible, SAP Retail optimizes quantities for procurement, converts existing purchase requisitions to purchase orders, groups purchase orders
together and, if necessary, also generates new purchase orders (for example, if the range of coverage is increased). Several purchase orders are combined
using a collective number.
When performing calculations, load building does not take into account scales, free-goods discounts, and target quantities and values defined in contracts. For
example, although the target quantity in a contract is 50 boxes and the target value is 10,000 euros, these restrictions will be exceeded if the load building
calculation for the range of coverage results in higher quantities.
For more information on how load building is integrated into the order optimizing process, see Ordering: Order Optimizing and the first diagram in Ordering .
Prerequisites
Load building is part of the business function Retail Enhancements (ISR_RETAILSYSTEM) that you usually activate with the Retail business function set.
The vendor for whom the system is to perform order optimizing is an external vendor.
A restriction profile is assigned to the vendor. This includes information on the minimum and maximum loading capacity for the means of transport used.
A truck must transport a minimum load of 300 kg, but can only carry a maximum of 27 pallets.
You maintain restriction profiles in Customizing for Materials Management under Purchasing → Order Optimizing → Load Building .
Think about the restrictions you want to use (such as minimum or maximum quantities, multiple quantities, weight or value).
For automatic load building, the Automatic Purchase Order indicator must be set in the purchasing data in the vendor master and the Automatic Purchase
Orders Allowed indicator must be set in the master records for the articles involved.
For load building to be used properly, article dimensions, weights and volumes have to be maintained in the master data (see
http://aiokeh.wdf.sap.corp:1080/SAPIKS2/content_get.sap?_CLASS=IWB_EXTHLP&_LOIO=120846FD470311D1894A0000E8323352Articles: Basic Data ).
If you use load building, you should also use forecasting so that the system can calculate the range of coverage of the stock and determine the additional
items and quantities required. You have to decide which forecasting method to use for each combination of article and site.
For more information on this topic, see MM – Consumption-Based Planning: Forecast Parameters .
Load building is based on the purchase requisitions and purchase orders created in requirements planning. You have to decide which planning method to use
for each combination of article and site.
Alternatively, you can configure the control parameters for automatic load building so that instead of accessing existing requirements elements, the system
generates requirements directly from the forecast values.
For more information on this topic, see Requirements Planning .
For many articles, it is better to place orders in a larger logistical unit (such as 3 pallets) rather than forecasting your exact requirements in the base unit of
measure (such as 288 pieces). In this case, you should use dynamic rounding profiles. Rounding profiles make it easier for you to fulfill restrictions, for
example, to fill an entire truckload. You have to decide how to define your rounding profiles and to which unit of measure the system should round off the
quantities.
For more information about this topic, see Dynamic Rounding Profiles .
When you implement load building, you should begin with a smaller selection of vendors and one distribution center to gather initial experience with the effects
of load building. You can then include further vendors and distribution centers as time goes on.
Decide on the vendors and distribution centers for which you want to use load building. You can use vendor sub-ranges as splitting criteria for purchase orders.
The system then optimizes documents for each vendor subrange.
Procedure
Load building can be run automatically or manually. Both methods differ in terms of the prerequisites that apply and the functions that are available. They can
also be used in different combinations:
You allow the system to simulate automatic load building and you then manually convert the result in the results list (if necessary, without the purchase order
being flagged as optimal through the assignment of a collective number) to purchase orders.
You always allow the automatic load building program to generate purchase orders. You can optimize and flag optimized purchase orders (achieved by
assigning a collective number) further in manual load building.
You only allow load building to create purchase orders when the system can flag the purchase order as optimized. You optimize quantities using the automatic
load building program. You only use manual load building in cases where the automatic load building program cannot find an optimal solution.
The following process variants are useful:
Variant 1
Starting automatic load building as a simulation run

See Order Optimizing: Automatic Load Building
Controlling results in the results list and convert to purchase orders.
See Order Optimizing: Results List from Automatic Load Building
Flagging optimized purchase orders by assigning a collective number
See Order Optimizing: Manual Load Building
Using additional quantities to enhance purchase orders that have not been optimized
See Additional Planning
Variant 2
Automatic load building with immediate creation of purchase orders

See Order Optimizing: Automatic Load Building
Controlling results and flagging optimized purchase orders by assigning a collective number
Variant 3
Automatic purchase order creation from purchase requisitions, no automatic load building
See Automatic Generation of Purchase Orders from Purchase Requisitions
Controlling purchase orders, optimizing by combining several purchase orders and flagging the optimized purchase orders by assigning a collective number
Variant 4
Creating purchase orders manually

See Creating a Purchase Order Manually (Vendor Known)
Controlling purchase orders, optimizing by combining several purchase orders and flagging the optimized purchase orders by assigning a collective number
The following special cases are only of minor importance in load building or cannot always be completely valuated when load building is performed:
Achieving better scaled conditions
Discounts such as free-goods discounts
Additional packaging
Reduced packaging
As a result, and due to the impact this would have on performance, the system does not take these factors into account.
Result
Purchase orders that fulfill all restrictions are bundled logically through the assignment of a collective number and are flagged as optimized.
1.2.2.3.1 Automatic Load Building
Use
In the automatic load building function, the system combines existing purchase requisitions and purchase orders. It only takes into account purchase
requisitions and purchase orders with a single vendor for a single site or site group.
Integration
For more information on the possible process variants that can be used, see Load The load meets all the requirements contained in the restrictions. Building .
Features
The system determines all the open purchase requisitions and promotion purchase orders placed with one vendor for each site or for a site group and groups
them together in a single load. It determines the total weight, total volume, total units and total value for each load. The results are documented in the list of
results:
Three different scenarios can occur:
The load meets all the requirements contained in the restrictions.
The system generates an appropriate purchase order. You can use the submission number to define a release strategy (see Release Procedure ).
The load does not meet the minimum requirements contained in the restrictions (for example, because the value is too low).
The system determines the articles that are to be ordered automatically in load building. From there it uses the forecast data to determine the articles
with the smallest days' supply for increasingly long periods. The system increases the number of pieces of this article until the restrictions for the load
have been met. The maximum number of days for which the system determines future requirements can be defined as required. The system does,
however, keep the shelf-life expiration date of the merchandise in mind.
As a result:
For articles with existing purchase items, an item is added in a new purchase order
For articles that already have purchase order quantities, the existing quantities are increased.
For articles without existing purchase orders and purchase requisition items an item is added in a new purchase order
If this results in the minimum requirements being met for the load, the system generates a purchase order and releases it automatically. If it
cannot release it, the system blocks it and flags the entry in the log for manual processing.
The load does not meet the maximum requirements contained in the restrictions (for example, because the load is too heavy).
The system generates a purchase order and flags it in the log as requiring manual processing.
The system lists all the purchase orders created and processed by automatic load building and the purchase requisitions and additional quantities for purchase
orders that were optimized but not created.
Activities
To run automatic load building, from the Purchase Order screen , choose Order Optimizing PO-Based Load Building Load Building Run.
1.2.2.3.2 List of Results for Automatic Load Building
Use
You use this function to check the results of automatic load building and create purchase orders from displayed purchase requisitions and additional items.
Integration
For more information on how to use the results list in the load building process, see Load Building .
Prerequisites
Before an up-to-date list is available, you must first run the Automatic Load Building function (see Automatic Load Building ).
Features
The system displays the results of the automatic load building run in an easy-to-read list. This list also details all the collective numbers that have been
assigned.
If the system was unable to generate purchase orders, it issues a list of all the errors logged.
Each result contains both the Purchase Order Completed and Rework Necessary flags. The following scenarios are possible:
PO created Manual Processing Required Comments
X Restrictions not fulfilled
X Standard
X X Restrictions overfulfilled
From the results list you can delete single or multiple lines. This results in less manual processing. Manually you can then ensure that the purchase order
bundles created by automatic load building fulfill a restriction profile. If you delete lines you reduce the totals of the actual values for a restriction profile.
From the results list you can generate purchase requisitions for additional quantities.
In Customizing for order optimizing you can define the number of calendar days for which an entry in the results list is valid for automatic load building. This
allows you to customize a short validity period and the validity periods of the entries that were created after a weekend or public holiday provide your
replenishment planner with sufficient time to check and adjust the results.
Activities
From the Purchase Order Screen , choose Order Optimizing Load Building Results List .
1.2.2.3.3 Manual Load Building
Use
Load building allows you to manually combine existing purchase orders. The system supports you in the following:
Combining purchase orders as required
Combining existing purchase orders and purchase orders for promotions
Processing purchase orders generated in automatic load building but not yet released
Releasing purchase orders
Displaying optimized purchase orders
You can also use the manual load building functions for vendors not participating in the automatic load building procedure.
Integration
For further information on the possible process variants, see Load Building .
Prerequisites
This transaction can only be used by users with the authorization M_BEST_EKO.
Features
Unlike automatic load building, manual load building can be used for ordering goods from several vendors in the one purchase order. If you use your own
means of transport, you can use restriction profiles not specific to any vendor.
Manual load building is used to combine purchase orders issued to different vendors for different recipients. The following cases are possible:
One vendor, one distribution center
Example
A vendor delivers the merchandise for several purchase orders in the one truck to a distribution center.
This results in lower transport costs and better purchase prices simply by making full use of the scaled conditions granted by the vendor.
Several vendors, one distribution center
Example
Your own company truck drives around all the vendors in the Boston area and brings the goods to one distribution center in New York.
This reduces transport costs. However, the smaller quantities mean that you cannot achieve any better conditions.
One vendor, several distribution centers
Example
A Boston vendor delivers a truck full of goods to several distribution centers in New York.
This results in lower transport costs and better purchase prices simply by making full use of the scaled conditions granted by the vendor.
Several vendors, several distribution centers
Example
Your own company truck drives around all the vendors in the Boston area and brings the goods to several distribution centers in New York.
This reduces transport costs. However, the smaller quantities mean that you cannot achieve any better conditions.
You can include fields you define yourself in the processing list for manual load building. User exit EXIT_SAPLWVLB_008 is available for this. The
following additional fields are allowed at most:
5 fields for texts
5 fields for indicators
5 field combinations for value and currency
5 field combinations for quantity and unit of measure
You can include a maximum of two self-defined additional pushbuttons fields in the processing list for manual load building. User exit
EXIT_SAPLWVLB_009 is available for this.
The system can calculate whether a purchase order on its own meets the restriction profile defined for a vendor. On the selection screen of manual load
building, you can specify that the system should only take these purchase orders into account.
You can go directly from the processing list of manual load building to an additional screen and display the vendor service level.
Activities
To run manual load building, from the Purchase Order screen , choose Order optimizing PO-based load building Manual load building.
1.2.2.3.4 Additional Planning
Use
This function enables you when you are entering or changing a purchase order to include other articles from a selection offered by the system in addition to the
articles already entered. This may be useful in the following cases:
When you wish to add items to a purchase order manually so that the minimum order value stipulated by the vendor is reached.
When you wish to order manually (after visually inspecting the stock).
You can use this function for creating or changing purchase orders ( Vendor known or Stock transfer ).
Prerequisites
The articles that the system proposes for the additional items have to be defined as orderable for the site ordering the merchandise.
Features
Additional planning can be called from the item overview of purchase orders.
On the initial screen of additional planning, you can narrow down the additional articles using the following selection criteria:
Vendor sub-range
Merchandise category
Promotion
Purchasing group
Stock planner
Planning cycle
Delivery cycle
Layout module
RP type
If you select the flag for selecting articles from the purchase order only, the system only displays items contained in the associated purchase order. You
can therefore use the additional planning screen as a kind of order control.
The system displays all items that already exist in the purchase order (and does not allow you to change them). It also displays as additional items the
articles listed in the receiving site that you can order from this vendor.
You can arrange the items according to the following criteria:
Article number
Promotion and article number
Promotion and range of coverage
Range of coverage
Self-defined (via user-exit)
The system calculates the range of coverage of the stock in days. It is calculated using the unrestricted-use stock and the daily consumption rate of the
previous period.
If desired, all the generic articles in the list can be broken down into their variants.
On the details screen of additional planning, you can include any additional fields you defined yourself. User exit EXIT_SAPLMDZU_003 is available for
this. The following additional fields are allowed:
5 fields for texts
5 fields for indicators
5 field combinations for value and currency
9 field combinations for quantity and unit of measure
On the details screen of additional planning, you can include a maximum of two fields you defined yourself. User exit EXIT_SAPLMDZU_002 is
available for this.
You can go directly from the details screen to displaying a promotion.
If you go directly from additional planning to posting a purchase order whose content does not match the restriction profile of the vendor, the system
issues a warning message.
The system offers a simple algorithm on the details screen that determines default values for the order quantity on the basis of the stock on-hand, the
order stock and consumption values. You can enter a required range of coverage manually.
Activities
1. In the item overview list of the purchase order screen, choose Purchase order Create with reference Additional items and narrow down the
selection as desired. Then press Enter .
2. The details screen is displayed.
3. To order additional articles, enter the desired quantity in the item concerned. You can also flag individual items as being returns items (see Returns ).
4. In the header, the aggregated order value for all the articles is displayed. This is the gross price. The system does not take any conditions into account,
and no prices are determined. The net price is displayed in terms of the purchase order price unit, which can differ from the base unit of measure and the
order unit.
5. When you copy over the items, all the items for which the quantity is greater than 0 are added to the purchase order.
1.2.2.3.5 Analysis Tool for Load Building
Use
You use this function to check the completeness of the load building settings in Customizing and in the vendor, vendor sub-range, site and article functions.
The system creates a results log in a tree structure, from which you can go directly to the relevant maintenance transactions (except for the Customizing
settings).
Features
The system performs the following tests:
Customizing
Does a number range for collective purchase orders exist?
Does a number range for the log exist?
Does an interval exist in the number range for collective numbers?
Does an interval exist in the number range for the log?
Have parameters been maintained for load building and investment buying?
Have restrictions been maintained?
Have descriptions for the restrictions been maintained in the language specified?
Have restriction categories been maintained?
Have descriptions for the restriction categories been maintained in the language specified?
Has at least one restriction profile been maintained?
Have descriptions for the restriction profiles been maintained in the language specified?
The system makes these Customizing checks for the language specified. This is important because the descriptions for restrictions or restriction categories,
foe example, are language-dependent.
Vendor
General checks
Has one purchasing organization only been maintained?
Has the indicator for automatic purchase orders been set at purchasing organization level?
Is there a restriction profile at purchasing organization level?
Checks in connection with vendor sub-ranges
Has the indicator for automatic purchase orders been set?
Has a restriction profile been maintained?
Checks in connection with sites
Vendor sub-ranges (checks in connection with vendors)
Site
General checks
Has a customer number been maintained?
Has a purchasing organization been maintained?
Has a logistics calendar been maintained?
Have control parameters for requirements planning been maintained?
Has the item number for purchase requisitions been maintained?
Has scheduling in line with info record or contract been maintained?
Checks in connection with vendors
Article
Has the net weight been maintained for every unit of measure?
Has the gross weight been maintained for every unit of measure?
Has the weight unit been maintained for every unit of measure?
Has the volume been maintained for every unit of measure?
Has the volume unit been maintained for every unit of measure?
If you narrow down your selection to sites or vendors, the system only makes these checks for the articles listed in the sites or at the vendors.
Activities
From the initial Retail screen, choose Purchasing Purchase order Environment Test Analysis tool for load building .
You can also go to the analysis tool from the implementation guide (IMG), by choosing Materials Management Purchasing Order Optimizing PO-
Based Load Building Analysis of Customizing Settings for Load Building. If you access it via Customizing, the system only checks the Customizing
settings. The language in which you are logged on is used.
1.2.2.3.6 Management Vendor Service Levels
Use
Use this program to calculate and manage vendor service levels. This includes:
Display of vendor service levels on the database and those calculated by the system
Deletion of existing vendor service levels
Calculation of new vendor service levels
The vendor service level indicates the percentage of the maximum potential sales (forecast) that a goods recipient (a plant or a store) can achieve with the
quantity of material available from the vendor. This figure is an important criterion in the load building functions. It defines which articles and quantities are
included by the system in the purchase order.
The vendor service level is calculated by the system using the vendor service level for individual articles.
Procedure
Start the vendor service level tool by selecting Purchasing → Purchase Order → Environment → Service Level by Vendor . You can enter the following
parameters:
In addition to selecting the vendor, you can limit the selection of vendors for load building. Do this by selecting Vendors for Load Building Only . This
limitation only influences the calculation of new data. A vendor for load building is a vendor for which a restriction profile has been created in the system.
The program can be run directly or in the background.
The vendor service level tool runs the following actions in the following sequence:
The system displays all data that is valid within the date interval entered in step 1. If the interval limits do not contain any data, the system selects the largest
possible interval (01.01.0000 to 31.12.9999.)
The system deletes all data that is older than the date entered on the selection screen. The check is run based on the to-date in the validity period.
Data is calculated for each load building combination, consisting of one vendor and an appropriate site. Before a load building combination can be created, the
same purchasing organization must be valid for both the vendor and the site concerned.
The system enters all messages generated during the program run in a message list.
The system displays the results using the ABAP List Viewer.
Data is always processed in the sequence detailed in step 3. It may be the case that existing data is displayed although the data was previously deleted in
step 2 or that data has been deleted that has been recalculated in the following step.
If you want to see the messages that were displayed when data was last processed, select Message List in the selection screen or in the output screen.
Example
Article 1 Article 2 Article 3 Total
Price EUR 4.00 EUR 4.00 EUR 0.40
Warehouse stock 200 400 0
Forecast value 400 800 0
Date ordered 08.10. 08.10. 08.10.
Delivery date 11.10. 11.10. 11.10.
Number of working days 1 1 1
Available stock (M) 1200 400 0
Sales quantity (V) 400 800 0
Lost future business volume EUR 0.00 EUR 1600.00 EUR 0.00 EUR 1600.00
(EU)
Future business volume (U) EUR 1600.00 EUR 3200.00 EUR 0.00 EUR 4800.00
Possible business volume (MU) EUR 3200.00
Vendor service level 66,7%
The individual values can be calculated as follows:

Delivery date:
Order data plus the planned delivery time estimated by the vendor. This is one working day.
Available stock (M):
Total warehouse stock and on-order stock.
Sales quantity (V):
Result of forecast values and number of working days.
Lost future business volume (EU):
EU = 0
EU = (V – M)price
Future business volume (U):
Result of sales quantity and the price.
Possible business volume (MU):
Difference of future sales (U) and lost future business volume (EU).
Vendor service level:
Quotient from possible business volume (MU) and future sales (U).
1.2.3 Dealing in Perishables
Use
Perishables are a special group of merchandise that usually has a short shelf life. The products are usually offered by a number of vendors, each with limited
delivery capacity. Typical examples of perishables are:
Fruit and vegetables
Meat and delicatessen
Fish and other seafood
Dairy products
Flowers
Procuring and distributing perishables (that is, issuing them to stores) is a dynamic process that usually takes place under extreme time pressure and requires
a lot of experience. The freshness and appearance of the products directly influence sales. It is therefore essential that the time between producing and selling
the goods is as short as possible. Ideally, it should not exceed 24 hours.
Dealing in perishables means having to work with considerable fluctuations every day. Often the weather conditions greatly influence demand, prices, and the
quantities delivered. Well-trained, experienced buyers are indispensable for ensuring that the quality of the produce and consequently potential sales do not
suffer.
The special functions described here for planning, procuring and issuing perishable produce ensure that the logistics processes involved are lean and
optimized. They enable you to analyze demand and the current state of the market fast, support you in making decisions and allow you to order merchandise
quickly and easily.
You can use these functions for typical perishable produce, but also for other articles offered by more than one vendor.
Prerequisites
You can only process perishables if you use SAP Retail .
Features
You can create a perishables planning list containing all the fresh produce relevant in a site over a particular period.
The perishables planning list contains key data for each article and vendor selling the article. You can use this information to obtain a good picture of the
market even before demand occurs, enabling you to react swiftly and make the best possible buying decisions.
Store sales over any period of your choice (the day before, the week before and so on) can serve as the basis for forecasting the quantities you need to
order.
You can forecast quantities, enter purchase prices, calculate retail prices, and order perishables all in the same transaction.
You can define the quantities and delivery dates for the individual recipients in an interactive issue list or change the proposals made by the system.
You can map push processes as well as pull processes using the perishables planning functions.
All the data created is collected in a special information structure that enables tight internal cost accounting in the individual stores and distribution
centers.
1.2.3.1 The Perishables Processing Procedure
Use
You can process perishables in three different ways. These differ according to how data is subsequently processed.
Perishables processing using an allocation table (push transaction)
This variant is designed for use in the head office. It is based on the use of allocation tables to distribute the total quantity ordered of an article among the
stores. You can either have the system automatically determine the quantities to be allocated to each store on the basis of an allocation rule or you can have
it propose the quantities for you to change before posting.
Perishables processing using a collective purchase order (pull transaction)
This variant is designed for use in the head office. It is based on the use of store orders, and generates collective purchase orders for the quantities generated.
Manual processing
This variant can be used in the head office and locally in the stores to procure and distribute perishable produce. It gives you the largest degree of control over
the whole process due to the options available for user intervention. You can combine parts of the push and the pull transaction.
Functions such as cross-docking or flow-through are possible for both push and pull transactions.
Prerequisites
The perishables planning process is based on assortment lists. A definition of it for both stores and distribution centers must already exist in the system.
Procedure
1. You specify the site for which you want to plan perishables.
2. You can plan perishables for a distribution center (and all the stores supplied by it) or for a single store.
3. You specify the articles you want to plan.
By defining a particular assortment list type, you can group the perishable products by (for example):
Perishables category (fruit, vegetables, meat products).
Perishability
List type for telephone sales
List type for purchases made at market
You also have the option of narrowing down your selection of articles, for example, to particular merchandise categories or promotions.
1. You define the following data on the tab pages:
Procurement and issue
You indicate the planning period.
Procurement
This information applies to the site from which you want to procure the articles. The perishables planning list can be extended by a vendor mentioned in the
master data.
Issue
This information applies to the stores for which you are planning. If you only want to plan for a distribution center, you do not enter any period here.
Settings
Here you can influence the content of the perishables planning list, by choosing to include or exclude certain details. The system only processes chosen
information. If you only select information that you really need you can considerably increase the performance of the perishables planning list.
You can also specify whether the system should prepare a new version of the assortment list every time and which POS sales period is to be taken into
account.
The key piece of information for the perishables planning list is generally the assortment list of the site for which you are planning. Usually, this assortment list
is newly generated at regular intervals. If new articles have been included since the last time the assortment list was generated or assignments have changed,
you can have the system generate a new assortment list before generating the perishables planning list.
The POS selling period indicates the period the system should use in the planning list for comparison purposes. The system displays the sales figures for this
period in the perishables planning list. It also uses these figures to determine proposed quantities.
1. You select a processing method.
The processing method determines the layout of the list and the processing activities that follow. You have the following options:
Allocation tables
This method supports push processes and integrates allocation tables for subsequent processing.
On the Allocation table tab page, enter the allocation table type and any other information you require for the allocation.
Choose Execute . The system generates the perishables planning list (see Perishables Planning List ).
The remainder of the process is described in Handling Perishables Using Allocation Tables .
This method supports pull processes and integrates collective purchase orders for subsequent processing.
You can define more data for this processing method on the tab page Collective purchase order .
The remainder of the process is described in Handling Perishables Using Collective Purchase Orders .
Purchase order
This method supports the manual procurement and issue of perishable products.
You can define more data for this processing method on the tab page Purchase orde r. The order document category, for example, determines whether the
system should create purchase orders, purchase requisitions, sales orders or deliveries. If you have already ordered the produce from the vendor (for example,
by phone), you can also have the system simply create an order copy for goods receipt and invoice verification. In this case, no messages are sent to the
vendor.
You can also, for example, enter an allocation strategy in the tab page Allocation table . Later, using this allocation the system can determine proposed
quantities in the issue list.
The remainder of the process is described in Handling Perishables Manually .
Result
The system generates the perishables planning list in line with the processing method you select and when this is posted it triggers different subsequent
processing steps.
1.2.3.1.1 Handling Perishables Using Allocation Tables
Purpose
This method supports push processes and integrates allocation tables for subsequent processing. Normally, no store orders exist.
Prerequisites
You must have generated a perishables planning list as described in The Perishables Planning Process and defined Allocation table as the processing
method.
Process Flow
1. Using the information displayed in the perishables planning list, you obtain a snapshot of the current stock situation, the produce required and that on
offer on the market.
2. For further information, see Determining Requirements for Perishables .
3. You enter the total quantity required of the articles you want to order.
4. If you need to negotiate with the vendors on the phone, you can have the system call the number directly. For further information, see Buying Perishable
Produce Over the Phone .
For further processing, the system does not take the purchase prices from the perishables planning list but determines them during the allocation
process.
5. You enter an allocation strategy and have the system determine the individual quantities for the recipients.
6. You can change these quantities as required. For further information, see Issue List .
7. You save the perishables planning list.
8. The system generates an allocation table.
9. If the system is not configured for follow-on documents to be generated automatically from allocation tables, you can process the allocation table
created using the Allocation Table functions.
For further information, see Allocation Table Processing .
10. If the system is not configured for follow-on documents to be generated automatically from allocation tables, you trigger follow-on document generation
manually.
11. For further information, see Allocation Table Follow-On Document Generation .
12. The system generates follow-on documents for the allocation tables.
Depending on how your allocation table functions are configured, the system uses flow-through or cross-docking for distributing the merchandise. For further
information, see Merchandise Distribution: Reference Scenario .
Results
Purchase orders for issue to a vendor, for example, and possibly store orders are created in the system for the required articles.
See also:
Allocation

Purpose
This method supports pull processes and integrates collective purchase orders for subsequent processing. Normally, store orders exist.
Prerequisites
You must have generated a perishables planning list as described in The Perishables Planning Process and defined Collective purchase order as the
processing method.
The required settings must exist in Customizing for collective purchase orders. (See Merchandise Distribution: Customizing Settings )
Process Flow
3. If there are any articles for which you want to order different quantities than those already requested by the recipients, you enter the quantities
concerned.
For further processing, the system does not take the purchase prices from the perishables planning list but determines them during the collective
purchase order process.
5. If you want to order any articles for which there was recipient order, you enter the quantities and delivery dates for the individual recipients.
6. For further information, see Issue List .
8. The system generates a purchase order for every vendor and places them with the distribution center on behalf of the stores. It then calls up the
Collective Purchase Order function. This function generates vendor purchase orders from the orders created, taking open purchase orders into account.
Depending on how your collective purchase order functions are configured, the system uses flow-through or cross-docking for distributing the merchandise.
For further information, see Merchandise Distribution: Reference Scenario .
Results
Purchase orders for issue to a vendor and possibly store orders are created in the system for the required articles.
See also:
Collective Purchase Order
1.2.3.1.3 Handling Perishables Manually
Purpose
With this processing method, you use perishables planning functions to procure and issue perishable produce manually.
Prerequisites
You must have generated a perishables planning list as described in The Perishables Planning Process and defined Purchase order as the processing
method.
Process Flow
3. You enter the required quantities and the purchase prices for the articles you want to order.
5. You define the required quantities and delivery dates for the individual recipients.
6. If you entered an allocation strategy on the initial screen, you can have the system propose quantities to be issued. For further information, see Issue
List .
8. Depending on how you configured the document category on the Purchase order tab page on the initial screen, the system generates a purchase order,
purchase requisition, delivery or sales order for the articles entered in the requested quantities. If you entered quantities for the individual recipients, the
system also creates purchase orders, for example, on behalf of the recipients for issue to the site carrying out the planning (these are store orders).
9. You can go to the purchase orders directly from the perishables planning list and change them as required. To do this, choose Environment Order
document .
Results
Purchase orders for issue to a vendor, for example, and possibly store orders are created in the system for the required articles.
See also:
Store Order
1.2.3.2 Perishables Planning List
Use
The perishables planning list is the basis of all the functions available in perishables planning. It contains an easy-to-read overview of all the articles to be
processed in a particular environment and all the key data pertaining to these articles.
You can use the perishables planning list for the following purposes:
Procurement and issue
Procurement only
Issue only
Integration
The perishables planning list is based on the existence of an assortment list.
The perishables planning list is required for subsequent activities involved in the processing of perishables.
You can navigate from the list display to other functions for procuring and distributing perishables. You can, for example, change existing purchase
orders.
You can navigate to Retail Pricing and the Perishables Information System.
When you post the perishables planning list, the follow-on documents may include store orders, allocation tables or collective purchase orders.
Prerequisites
The articles must be assigned to an assortment list.
The articles must be listed in the site for which you are planning.
A vendor master record must be maintained in the system for the vendors involved.
If you want to use the Perishables Information System, you must have activated the update function for the perishables information structure S160 in
the article type identification of the article type.
Features
You plan perishables for one site at a time, for example, for a store.
If you plan for a distribution center, the perishables planning list also contains information on all the sites supplied by the distribution center in which the article
concerned is listed.
The perishables planning list contains a line with all the relevant input fields and information for each article selected on the initial screen, and for each
vendor from which you can order the article.
You can plan and calculate prices for each line in the perishables planning list.
The layout of the list differs depending on the processing method selected on the initial screen. For example, the field for entering the net price is only
ready for input if you selected Purchase Order as the processing method.
In the standard configuration of SAP Retail, the perishables planning list contains the following tab pages:
This tab page contains, for example, a number and description of the article and the entries the user can make for the purchase order quantity and net price
(only in the Purchase Order processing procedure).
Overview
This tab page contains entries from Retail Pricing (that you can only display), for example, the purchase price, margin, sales price.
Information
This tab page contains entries from the Perishables Information System (that you can only display).
Delivery Phase
This contains information on the delivery phases planned. Alternatively, you can also enter the order quantity here. If you make any changes here, they affect
the planning list tab page.
Setting
This contains information on allocation tables, for example. If you selected the Allocation Table processing methods, you can also enter an allocation rule
here.
The contents of the tab pages are different views on the articles that were selected on the initial screen of the perishables processing together with associated
information. By simply switching tab pages, you can display the information you currently require.
You can configure the tab pages and their contents. For more information, see: Configuring the Perishables Planning List .
You can arrange the lines in the perishables planning list using the following criteria:
Article (or variant)
Vendor
Merchandise category
Choose in the menu Edit Sort by and the relevant menu point.
You can sort the list by selecting the required column and choosing Sort descending or Sort ascending . If you decide on a particular sort sequence on one
tab page, this is used in the others.
You can also search for a particular character string in the list.
You can set a filter to reduce the information displayed and make the list easier to read. If you set a filter on one tab page, this is used in the others.
You can define the quantities to be issued to the individual recipients (your stores, for example) by selecting a line and choosing Recipients. For more
information, see Issue List .
You can display environment information or navigate to other functions. For more information, see: Environment Information and Navigation Options .
The perishables planning list can be updated at any time. This is useful if, for example, you want to adjust the field content taken from the info structure
following posting.
The purchase price and net purchase price for each vendor and article are displayed for your site in the perishables planning list. The purchase price
entered is copied in the warehouse order and direct delivery order to the purchase order. The net purchase price (the purchase price minus discount) is
generally the price negotiated.
Note
The allocation table and collective purchase order functions do not use the prices in the perishables planning list but calculate them separately. You
therefore cannot enter purchase prices in the perishables planning list in this processing procedure.
The system highlights the lines in which you entered order quantities.
You can simulate the posting transaction to test the settings. The system generates a detailed log that includes the data and messages produced in the
last process.
The function Generate creates the necessary documents. The entries in the purchase order quantity column are deleted and the ordered quantities in
the purchase order column are displayed.
If you enter a new quantity in the Purchase Order Quantity field and save the list again, the system posts more purchase orders for the quantities entered
last.
The system records all the postings with the relevant data (posting time and user) in a confirmation log.
With the Save function, you can save the perishables planning list and proceed with the perishables planning at another time.
You can regularly delete the perishables planning list using a deletion report that can be planned.
Activities
1. From the Retailing screen, choose Purchasing Requirements planning Purchase order Requirements planning for perishables .
1. Enter the required selection criteria and choose Execute . For more information on the selection screen, see The Perishables Planning Process .
1. Enter the required order quantities and prices in the perishables planning list, and make sure that all the order quantities and prices you do not require are
deleted.
1. If necessary, navigate to the issue list. (See Issue List )
1. Choose Save .
To avoid unnecessary runtimes when the system is preparing the perishables planning list, please note the following:
Create small assortment lists.
Use mixed assortment lists.
If possible, avoid calculating mixed prices.
1.2.3.2.1 Configuring the Perishables Planning List
Use
You use this function to configure the layout of the perishables planning list in line with the processes performed in your company and to meet the
requirements of the users. You can, for example, add other fields or switch off columns. You can save the settings as a variant or have them appear system-
wide.
Prerequisites
Before you can use this function, you must generate a perishables planning list (see Perishables: Perishables Planning List ).
Features
You can arrange columns by topic to make it easier to read. There are three ways of doing this:
Using a screen variant
You create a screen variant using transaction SHD0 and activate this using user exit EXIT_SAPMWOG1_015 . The new screen variant is
available system-wide.
See BC – Changing the SAP Standard: Transaction Variants and Screen Variants
Using a transaction variant
You use transaction SHD0 (for example, for planning for individual stores) to create a variant of WDFR with a new transaction code of your
choice.The new transaction is available system-wide under the new transaction code.
See BC – Changing the SAP Standard: Transaction Variants and Screen Variants
Using table settings
All users can change these table settings, save them as a variant and define their own standard settings. The width and position of each column
can be configured.
See Getting Started: Creating Table Control Variants
You can use additional quantity, price and text fields. These fields can be defined using user exit EXIT_SAPMWOG1_002 and switched on using a
screen variant. Further user exits are available with which you can fill fields.
In the standard configuration of the perishables planning list, the system lists all the vendors of an article. Alternatively, you can change the display
using a user exit so that each article is only listed once. You can then enter the vendor you want in a field that is ready for input.
The following describes where user exits are planned and illustrates where these can be used:
1. Determine valid assortment list
2. Determine vendor from assortment list
User exit EXIT_SAPMWOG1_011 : exclude vendor
You can have the system find vendors on the basis of your own criteria and exclude them from further processing.
The system carries out the following processing steps for each vendor:
3. Find all the articles assigned to the vendor.
User exit EXIT_SAPMWOG1_012 : exclude vendor
You can, for example, exclude articles for further processing that the user is not allowed to order.
4. Find combinations of recipients and articles
5. Find perishables assortment lists
User exit EXIT_SAPMWOG1_010 : create or add lines in perishables planning list
You can, for example, remove all vendors except one from the list and make the vendor field ready for input.
6. Find information in info structure and Pricing
User exit EXIT_SAPMWOG1_005 : change field content of perishables planning list
You can, for example, change the results of a sales price calculation or transfer the data from an external system.
User exit EXIT_SAPMWOG1_013 : change field content of issue list
You can, for example, transfer data from an external system
User exit EXIT_SAPMWOG1_002 : switch on individual columns
You can add indicators such as chemically treated
User exit EXIT_SAPMWOG1_015 : activate screen variant
You can specify a role-based screen layout
Note
Using method TX_XX_FILL from BAdI WDFR_BADI you can find and prepare data for the perishables planning list. Steps 1 and 6 do not run
when the BAdI is implemented.
7. Display perishables planning list

8. Display issue list
9. Close issue list
User exit EXIT_SAPMWOG1_008 : check individual fields
User exit EXIT_SAPMWOG1_009 : check data entered
You can, for example, have the system check if the order value is within the maximum limit set.
10. Display perishables planning list
11. User entry
If the user presses Continue , the system proceeds directly to step 7.
If the user chooses Refresh , the system proceeds directly to step 7 using the following user exit:
User exit EXIT_SAPMWOG1_014 : change field content
If the user chooses Generate , the system performs the following activities:
User exit EXIT_SAPMWOG1_004 : check data entered in the perishables planning list
You can, for example, have the system check if the order value of individual items or of the whole purchase order is below a certain limit
and, if the limit is exceeded, prevent posting.
You can, for example, prevent posting.
12. If user exit EXIT_SAPMWOG1_006 returns an error, the system refuses to proceed with step 7.
13. Create purchase orders
User exit EXIT_SAPMWOG1_007 : generate additional data or delete temporary data
Using methods FDIS_BELEGE_GEN_MANU, FDIS_BELEGE_GEN_PULL and FDIS_BELEGE_GEN_PUSH from BAdI WDFR_BADI, you can
create specific document generation. Step 13 does not run when a BAdI is implemented.
14. Proceed to step 7
See also:
Changing the SAP Standard (BC)
1.2.3.2.2 Environment Information and Options for Going to Other

Functions
Use
You can branch from the perishables planning list to the host of information you need to obtain an overview of the current market situation. You can also go
directly to some maintenance functions.
Prerequisites
Features
You can go to the following information directly from the perishables planning list:
Article
The system displays the article master data of the article selected.
Vendor
The system displays the vendor master data of the vendor selected.
Order document
If a specific article has already been ordered from the vendor in the line selected, the system displays the purchasing documents created. You can also
change the purchase order as required.
Planning list
You can go to a special planning list (for procuring produce at a market, for example) directly from the perishables planning list. You can print the planning list
and transfer it electronically (see Procuring Perishables from a Market ).
Perishables Information System
This takes you to the controlling functions for perishables. Comprehensive functions are available, such as manual analyses, drill-down/switching and ABC
analysis. The early warning system functions are also available, including interactive and periodic analyses.
Lists
Display purchase orders
The system displays all the vendor purchase orders for a site placed in the order period selected. You can branch from the list to the purchase order details.
Display purchase requisitions
The system displays all the purchase requisitions for a site in the order period selected. You can branch from the list to the purchase requisition details.
Availability overview
The system displays the availability details of the articles selected.
Current stock and requirements list
The system displays the current stock level and the requirements that exist for the article selected.
Issue list
You can define the quantities and delivery dates for the individual recipients of each article. (See Issue List )
Activities
Position the cursor in the line for which you want to receive more information and choose the desired function.
1.2.3.3 Procuring Perishable Produce

The following sections describe functions that enable you to procure perishable produce quickly and conveniently.
You can branch from the perishables planning list to functions for determining requirements, maintaining prices, and entering purchase orders.
1.2.3.3.1 Determining Perishables Requirements
Use
Dealing in perishables means having to work with considerable fluctuations every day. Often the weather conditions greatly influence demand, prices, and the
quantities delivered. This function supports you in determining requirements based on stock on-hand, existing purchase orders, and historical data.
Prerequisites
If you want to use the Perishables Information System, you must have activated updating of perishables information structure S160 in the article type
identification of the article type.
Features
The perishables planning list contains a wealth of information on articles, vendors, sales quantities, and prices. You can branch to detailed information
on much of the information displayed direct from the list (see Environment Information and Options for Going to Other Functions ).
You use the perishables information structure (S160) to find the historical data. It contains all the key characteristics and figures required for
processing and monitoring perishables. All goods movements of perishable produce are updated in this info structure.
The info structure can be analyzed using the standard analysis tools. With critical key figures, you can have the system generate a message or a workflow
item using the early warning system and assign them to an employee
The following fields are relevant for perishables requirements:
Characteristic
Article
Distribution center
Store
Key figures
Stock transport orders (store orders)
Sales orders
Order volume
Sales value (as done with external customers at POS - for example, store sales)
The historical data displayed in the perishables planning list helps you in using your experience to decide which quantities to order. To make it easier for
you, the system can also calculate the quantity of each article that still has to be purchased. This is calculated as follows:
Remaining quantity = Total purchase orders over DC delivery period
Example
+ current unrestricted-use stock (stock on-hand)
– existing store orders over store delivery period
The following example illustrates how the Remaining quantity field is used:
Total purchase orders over DC delivery period: 100 pc
current unrestricted-use stock (stock on-hand): 20 pc
– existing store orders over store delivery period: 50 pc
Remaining quantity calculated: 100 pc + 20 pc – 50 pc = 70 pc
You can use the user exit EXIT_SAPMWOG1_010 to replace this rule with one of your choice.
1.2.3.3.2 Buying Perishable Produce Over the Phone
Use
You use this function to make a telephone connection for negotiating with a vendor or seller of perishables while in Requirements Planning for Perishables.
Prerequisites
Your phone system must support dialing from the SAP system.
SAPphone must be configured and your telephone system linked up to it.
The partner function PE or the contact persons at the vendor must be maintained.
Features
Using SAPphone , the system can automatically call the number of your contact person from the telephone at your desk. To do so, it uses the partner
function PE (perishables) to find the right contact person and telephone number.
If the perishables contact person has not been maintained, the vendor proposes the main telephone number of the vendor. If more than one contact person
has been maintained, you can select which one you want to call.
Activities
Position the cursor on the vendor you want to call and select Call vendor .
Note
This function can only be selected if SAPphone has been configured to operate in your system.
See also:
Working with SAPphone
1.2.3.3.3 Procuring Perishables at the Market
Use
You can generate a special planning list for those articles to be bought at a market. This list can be used as a worklist for the buyers.
Prerequisites
Features
On the selection screen, you can narrow down the perishables assortment selected to those products bought at a market. The system can tell from the
assortment list type which articles are procured at a market and prepare a market planning list for you.
You can print the planning list or transfer it electronically.
The buyer enters the quantities to be ordered and the cost of the articles to be procured from the vendors in the printout. The articles ordered can then
be entered directly in the system so that the order values are available in the system.
Alternatively, you can wait until the goods receipt is posted and then have the system generate a purchase order in the background. Purchase orders are
required for Invoice Verification, for example.
The system uses the ABAP list viewer (ALV) to display the list.
The ABAP list viewer displays lists in the SAP system in a standardized format. It contains a function for creating simplified lists and for dynamically
creating list variants.
You can:
use standard display variants pre-configured by SAP
create your own display variant
define sort sequences
arrange the lines in descending or ascending order in line with the value assigned to the column
set filters
have lines displayed that meet certain criteria
create totals and sub-totals
You can configure the layout of the perishables planning list any way you like using display variants. For example, you can:
move columns
hide columns
create totals
define sort sequences
transfer the planning list electronically
print the planning list
Activities
To prepare a planning list for going to market, choose Environment Send… Print planning list
See also:
CA – Cross-Application Components: ABAP List Viewer
1.2.3.4 Issuing Perishable Produce

The issuing of the produce ordered from the vendors to the individual recipients (i.e. the distribution of the produce) is integrated in the perishables planning
process.
You can go from the perishables planning list directly to the issue list and specify how the articles should be distributed among the recipients and when they
should be delivered. You can define more than one delivery date for each recipient.
The system generates purchase orders for the distribution center for issue to the vendor and also purchase orders for the stores for issue to the distribution
center.
1.2.3.4.1 Issue List
Use
You can go from the perishables planning list to an issue list for each combination of article and vendor. You can define the recipients, the quantities they are
to receive and the dates on which the deliveries are to be made. If required, you can also define a number of delivery phases.
The recipients are those sites (usually stores) that are supplied by your distribution center. The articles must be listed in those sites.
Prerequisites
Before you can use this function, you must generate a perishables planning list (see Perishables Planning List ).
Features
You can specify the processing method:
Via warehouse
The vendor delivers the articles to the distribution center. The products are picked for the individual recipients and sent to them in a separate step.
The system generates purchase orders and places them with the vendor on behalf of the distribution center. It also generates further purchase
orders and places them with the distribution center on behalf of the recipients. If the distribution center and the recipient do not belong to the same
company code, a standard purchase order is generated instead of a stock transport order.
The order quantity does not have to be the same as the total quantities you entered for the individual recipients. When picking the products, you
can use stocks that are already in the distribution center. Any remaining quantity is retained at the distribution center.
Direct delivery (third-party processing)
The vendor delivers the articles directly to the recipients.
The system generates purchase orders and places them with the distribution center only on behalf of the recipients.
The total quantities for the individual stores must be the same as the order quantity.
In the standard configuration of SAP Retail, the issue list contains the following tab pages:
Recipient planning
This tab page includes the description, name and location of the recipient and a field for you to enter the order quantity.
Information
This tab page contains information from the Perishables Information System (which you can display only)
Delivery Phase
On this tab page, you can specify the dates on which the produce is to be delivered to the recipients. You can make sure, for example, that a
particular article is always delivered at 8 a.m., 12 noon and 5 p.m. to ensure best possible freshness. The total quantities for the individual
schedule lines must be the same as the order quantity.
If you change the order quantity on this tab page, this affects the quantities on the Recipient planning page.
Setting
This contains information on allocation tables, for example.
The content of the tab pages represent different views on the vendor/article combination selected on the initial screen together with the various
information. The possible recipients (such as stores) are listed. By simply switching tab pages, you can display the information you currently
require.
You can configure the issue list to meet your own requirements. For more information, see Getting Started: Making Table Settings .
You can also sort the issue list by selecting the required column and choosing Sort descending or Sort ascending . If you decide on a particular sort
sequence on one tab page, this is used in the others.
You can also search for a particular character string in the issue list.
You can set a filter to reduce the information displayed and make the list easier to read. If you set a filter on one tab page, this is used in the others.
If you specified an allocation strategy on the Allocation table tab page on the initial screen of the perishables planning function, you can have the
system propose how to distribute the produce. In this case, choose Distribute .
You can display a detailed log of the data and messages that were generated in the last distribution run.
Activities
1. In the perishables planning list, select a line and choose Recipients .
The issue list is displayed.
2. Enter the required quantities in the issue list and any required delivery dates on the Delivery phase tab page.
If you change the order quantity on the Delivery phase tab page, this affects the quantities on the Recipient planning tab page and vice-versa.
3. Choose Back .
1.2.3.4.2 Maintaining Sales Prices for Perishable Produce
Use
The system can calculate the following prices (in a two-step price calculation) using the Pricing component:
Transfer prices (if you procure perishables via a distribution center)
Sales prices
Purchase prices or price lists for individual stores
Prerequisites
Features
When you call up Sales Price Calculation, the system analyzes the vendor and the purchase price.
If you are planning to procure a particular article from more than one vendor at the same time, the system calculates the prices using an average
purchase price and not the price charged by a particular vendor.
The system updates the new sales prices on the database. These new prices are thus available for subsequent functions. This allows the system, for
example, to find the most up-to-date retail prices during POS outbound processing for transfer to the cash registers.
Activities
Position the cursor on an article on the screen for displaying the perishables planning list, and choose Maintain prices . The system calculates the sales
price for the article selected. If the article is available from more than one vendor, make sure that the cursor is on the line with the vendor you want.
See also:
Pricing
1.2.4 Vendor-Managed Inventory (VMI)
Purpose
This scenario describes how vendors can plan material requirements in the customer's company. Vendors can only offer this service if they have access to
stock figures and sales data at the customer.
In an ERP system, you can implement vendor-managed inventory (VMI) from a vendor point of view and from a customer point of view. VMI would typically be
used when the manufacturer of consumer products plans the replenishments of the products at a retailer.
You can use VMI functions independently of each other and also in different contexts.
Integration
The following components are used:
Component Function
Vendor (in customer system) Transferring stock and sales data
Sales order (in vendor system) Receiving stock and sales data via EDI
Planning replenishments for customers
Purchasing (in customer system) Generating purchase orders for an order acknowledgment received by EDI
Process Flow
It is assumed that both the vendor and the customer use an ERP system from SAP.
1. Transferring stock and sales data via EDI

The customer uses the message category PROACT to transfer the current stock as well as the historical sales data or the forecast sales data for a
particular article to the vendor.
For further information, see VMI: Transferring Stock and Sales Data to the Vendor .
2. Receiving stock and sales data via EDI
The sales data for the article is entered in an information structure in the information system S130 in the vendor system. The stock data is entered in
the replenishment master data of the article.
3. Planning replenishments for customers
Using the sales data, vendors can forecast future expected sales of the articles concerned at their customers’ sites. Alternatively, forecast values
obtained from the customer can be used.
Vendors first of all plan replenishments for the articles based on the current stock levels and any forecast values. The replenishment planning program
calculates the requirement and generates a sales order as a follow-on document.
Sales order data is transferred to the customer by EDI in the form of an order acknowledgment. The message category ORDRSP is used for this.
For further information, see Customer Replenishment .
4. Generating purchase orders for an order acknowledgment received by EDI
The order acknowledgment from the vendor is converted in the customer’s system to a purchase order. If a purchase order cannot be generated,
because the data is incomplete, for example, the system triggers a workflow.
If subsequent messages on this transaction are to be transferred at a later date by the vendor to the customer (for example, indicating a change in the
order or a shipping notification), the purchase order number must be transferred to the vendor's system. The vendor system can then enter this number
as a form of identification in subsequent messages, enabling the customer system to find the relevant purchase order.
If the order number should be transferred automatically to the vendor system after the purchase order has been generated, you have to enter the
message variant VMI in the partner profile for the EDI message category ORDCHG.
5. Entering the purchase order number in the sales order
The purchase order number in the customer system is entered as a reference in the associated sales order.
1.2.4.1 VMI: Transferring Stock and Sales Data
Use
You use report RWVMIPAD to transfer article information to your vendors by electronic data interchange (EDI) on historical and forecast sales, current stock
on-hand and current open order quantities (on-order). You can specify the sites and vendors for which you want to transfer data. If the system finds data
requiring transfer, the report generates an IDoc of the message category PROACT for each vendor and site.
The vendor’s system can now compare the open order quantity for an article with that in the customer system. The system uses the historical sales data to
forecast future sales of the article for the customer. Alternatively, the customer can also transfer forecast sales data if a forecast was previously run. If the
vendor is also the manufacturer of the article, the data can be used to plan and control production.
Prerequisites
The following requirements must be met before sales and stock data can be transferred for an article:
A purchasing information record must exist for the vendor to whom you want to transfer data.
The article master record must be maintained for the site for which data is to be sent.
The system can find a control profile for the article.
You configure control profiles in Customizing. You can assign a vendor a control profile in the vendor master record at purchasing organization level. If you
have maintained different data at another level, you can also enter a control profile there. It is possible to enter different data at the following levels:
Purchasing organization, vendor sub-range, and site
Purchasing organization and vendor sub-range
Purchasing organization and site
The system first checks whether different data exists. If it does, the most precisely defined level is determined, in accordance with the sequence given above.
If a control profile is maintained at this level, this profile is used. If a control profile is not maintained, the control profile at purchasing organization level is
used. If a control profile is not defined at purchasing organization level either, the default control profile, which you can enter on the selection screen for the
report, is used.
The article meets all the criteria of the selection key defined in the control profile found.
1.2.4.1.1 Transferring Sales/Stock Data to Vendors
Use
You can use this process to transfer historical and forecast sales data, current stock on-hand and current open order quantities (on-order) to your vendors
using electronic data interchange (EDI). You can specify the sites and vendors for which you want to transfer data. Data can be transferred as part of the
following strategies:
Quick response
If vendors have access to information on their customer sales data, they can improve long-term planning, respond faster to customer requirements, and
increase the vendor service level without managing customer inventory.
Vendor-managed inventory (VMI)
Using historical sales data, vendors can forecast future expected sales of the articles concerned at their customers’ sites. Alternatively, customers can also
transfer forecast sales data directly. Vendors first of all plan replenishments for the articles based on the current stock levels and any forecast values.
Vendors are responsible for planning replenishments of their products at the customer’s.
Category management
A vendor is category captain. As such, not only is the vendor responsible for planning replenishments of their products from a retailer, the vendor is also
responsible for planning replenishments of other products in the same category.
Procedure
1. Choose the vendors and sites and state the time period for which historical and forecast sales data are to be found.
1. If required, enter a control profile that should be used if none is found in the vendor master record.
1. The system finds - for each combination of vendor and site - the articles that can be procured from the vendor and are maintained in the site entered.
1. The system finds the control profile valid for each article/vendor/site combination.
1. The system analyzes the selection key for the control profile and finds all the articles for which data is to be transferred.
1. The system uses the control profile to determine the sales data and stock figures for the articles concerned.
1. You transfer the IDoc.
Result
The system generates an IDoc containing the relevant stock figures and sales data for each combination of vendor and site. The IDoc is sent to the vendor by
EDI.
1.2.4.1.2 Transferring Stock/Sales Data to the Vendor: Procedure
Use
Use this procedure to transfer stock and sales data to your vendors.
Procedure
1. On the Transfer Stock and Sales Data screen, enter the vendor to which you want to send data, and the issuing sites.
2. Enter the time period for the historical sales data. If necessary, state the time period for which sales data is to be forecasted.
3. (Optional) Enter a control profile that should be used if none is found in the vendor master record.
4. Execute the program.
5. A list of results is displayed for each site and vendor of the articles selected and all the relevant data (stock and quantity on-order as of today, historical
and forecast sales data over the period indicated). The list contains the data transferred in an IDoc. You can display the list using the list viewer,
enabling you to use all the scrolling and sorting functions offered.
6. Transfer the data. You can either transfer the data displayed on the screen on its own (List Send IDoc ) or send all the IDocs in the one step (
List Send all IDocs )
Note
You can display the IDocs transferred using the report for displaying stock and sales data transferred.
1.2.4.1.3 Determination of Stock and Sales Data
Use
This function is used by the system to determine which data has to be transferred to the recipient.
Integration
The data transferred originates as follows:
The sales figures are determined from an information structure in the Information System. In the standard system, information structures S130 and
S083 are defined for this.
The stock data is determined from the article master data. You can check this using the stock overview function.
The system takes the information on open on-order quantities with the vendor from a list of open purchase orders for the article. You can display this list
by choosing Purchasing Purchase order Purchase order List displays By vendor.
Prerequisites
You define the scope of the data to be transferred for an article in Customizing in the control profile valid for the article. The control profiles can be maintained
in Customizing for Purchasing in the Message section under EDI.
Features
Data Defined
You can transfer the following data:
Current stock level in the relevant site
In Customizing, the stock types you want to be included in the stock figure transferred can be assigned to the control profile.
Current open quantity on-order at the vendor for the site.
Historical or forecast sales data for the site
The sales figures are taken from an information structure in the Retail Information System (RIS) and always refer to a period. By entering a time period on the
selection screen of the report, you can determine the number of periods for which you want to transfer sales data.
You can transfer the following categories of sales data:
Historical sales data
Forecast sales data
Historical sales data for promotions
Forecast sales data for promotions
You have to maintain the access parameters for an RIS information structure in the control profile for each category of data to be transferred. The standard
configuration of SAP Retail contains information structures S083 and S139 for historical and sales data not specific to any promotions.
The information structures contain at least one key figure as a comparison quantity. The updating of this key figure prevents the same sales data being
transferred more than once (see Comparison Quantity ). The comparison quantity is of internal relevance only and is not transferred to the vendor.
Historical or forecast sales data for promotions can be transferred via information structure S130 . A second key figure exists as a comparison quantity for
promotion data. You can also use self-defined information structures for transferring sales data.
Changing Data to Meet Your Own Requirements
You use user exit EXIT_SAPLWVMI_001 to change the data as required before it is transferred.
1.2.4.1.4 Comparison Quantity
Use
The comparison quantity is transferred to the recipient to enable them determine whether the same data has been transferred twice by mistake. The
comparison quantity is the sum of all quantities already transferred to the recipient during the current period. The quantity to be transferred for a period is the
difference between the current quantity and the comparison quantity for the period.
Example
A retailer working with vendor-managed inventory sends the vendor the sales data of an article by EDI. The vendor is the manufacturer of the product. He uses
the data to forecast his customer’s future requirements and plan his own production.
The sales figures are transferred once a month. On January 1, a quantity sold of 1000 pieces of article 1 was transferred to the vendor. The January figures
are as follows:
Quantity sold = 1000
Comparison quantity = 1000
On January 31, the new sales figures for January are to be sent.
In the meantime, a total of 1800 pieces of the article has been sold. The most recent figures for January are therefore:
A quantity of 800 is therefore transferred as the additional sales figure for January (quantity sold – comparison quantity = 1800 - 1000 = 800). The quantity
transferred is added on to the comparison quantity, leading to the following key figures for January:
1.2.4.1.5 Determination of the Articles Affected
Use
The articles for which data should be sent are determined via the selection key defined in the control profile. The standard system contains the only selection
keys that are possible.
Example
The following examples illustrate which data must be maintained for a particular selection of articles:
Article selection Data in the vendor master
All articles of a vendor Control profile with selection key S1 at purchasing organization level
Articles in a particular vendor sub-range with a suitable RP type. Control profile with selection key S 2 at purchasing organization/VSR level
All articles in a particular merchandise category in a store. Control profile with selection key S0 at purchasing organization/VSR/site level (if all
articles in the VSR belong to the merchandise category)
Note
If the system finds the selection key SO in the control profile for an article, the system transfers stock and sales data on the article and also on all other
articles in the merchandise category to which the article belongs. This information could be useful, for example, for category management as part of an
efficient consumer response (ECR) strategy. The control profile of the article concerned is used as a basis for determining the sales and stock data of the
other articles in the merchandise category.
1.2.4.2 VMI: Receiving Stock and Sales Data
Use
An ERP system can receive and process stock and sales data transferred by EDI using the message category PROACT . This enables a manufacturer, for
example, to receive the current stock and sales data from a customer so that the manufacturer can plan replenishments for the customer.
Integration
The data received is updated in the Information System and in the article master data for Replenishment.
Prerequisites
Customer master data must be maintained for the company sending data to you. You have to create a customer master record and assign the partner
function 'sold-to party' to it. The sold-to party is also the EDI partner with whom you exchange messages.
You must also create a customer master record for each customer site for which you want to plan replenishments. All customer master records
belonging to a company must be assigned to exactly one sales area. The numbers of these master records have to be entered in the partner functions of
the sold-to party as ship-to parties (goods recipients). You can enter the external number of each goods recipient in the company of the customer, so
that when an IDoc is received, your system can convert the external number to the customer number in your system.
You must maintain an EDI partner profile for the customer master record which has the partner function 'sold-to party'.
In Customizing for Shipping, the customer having the partner function sold-to party must be assigned to a sales area for the configuration of EDI
partners
The article number of the customer can be converted to an article number in your system during IDoc processing. You must therefore create a customer-
article information record and enter the article number of the customer there.
Replenishment article master data must be maintained for the customer concerned.
Features
The set of data received is processed automatically by the system. Before standard processing begins, the system calls the user exit
EXIT_SAPLWVMI_002 which you can use to change and process data as required. You use a special transaction to display the data of the inbound IDoc.
In the standard system, the information received is processed as follows:
Sales data
The customer sales data is adopted in information structure S130 . Separate fields exist for regular and promotional stock data. A separate version of
the information structure exists for updating historical data and one for updating forecast data. The standard configuration contains the following
versions:
Actual version (for historical data): 000
Active version (for forecast data): 000
You can change these Customizing settings in the general control parameters for Replenishment (consumption-based planning section). The
sender data is converted in line with the periods defined in the information structure of the recipient (i.e. your system).
Stock data
Stock data is updated in the Replenishment article master data, and can be used, for example, to plan replenishments for a customer.
Order data
The open purchase order quantity is also adopted in the article data of Replenishment. You can display this data in the parameter overview screen of
Replenishment.
1.2.4.3 VMI: Planning Replenishments for Customers
Use
You use this function to plan replenishments for a customer. The replenishment planning run results in sales orders that you transfer to the customer by EDI in
the form of an order acknowledgment. This enables vendors, for example, to calculate customer requirements automatically and supply the customers with
exactly the quantities they require.
Integration
The system determines the relevant stock data from the replenishment article master data. The sales data received by EDI is stored in information structure
S130 of the information system and analyzed in replenishment planning. Sales data received that refers to promotions is not taken into account in
Prerequisites
Customer master data must be maintained for the company sending data to you. You have to create a customer master record and assign the partner
function “sold-to party” to it. The sold-to party is also the EDI partner with whom you exchange messages.
belonging to a company must be assigned to exactly one sales area. The numbers of these master records have to be entered in the partner functions of
the sold-to party as ship-to parties (goods recipients).
Replenishment article master data must be maintained for the recipient concerned.
The customer must have sent you the current stock information for the articles to be planned. The system runs replenishment planning to calculate the
target stock for the customer using a forecast. The forecast requires that you have access to the sales data of the customer from the previous periods.
You have to configure message determination so that order acknowledgments are sent to the customer as EDI messages for the sales orders
generated.
Scope of Functions
Replenishments are planned in the following steps:
Planning
During the planning phase, the system determines the replenishment requirements. Two methods of planning can be used, depending on the RP type involved:
Planning using a static target stock
If the article is assigned the RP type for static target stock (standard RP), the requirements are calculated as follows:
Requirement = target stock - current stock figure for customer
Planning using a dynamic target stock
If the article is assigned the RP type for dynamic target stock (standard RF), the system calculates the target stock based on the future sales forecast.
This is only possible if you previously forecast the sales in flexible planning or if the customer transferred the sales forecast data to you. The target
stock is calculated as follows:
Target stock = total sales quantities forecast during the target range of coverage + safety stock
If you entered a minimum or maximum target stock in the replenishment article master data, you define the target stock even further. Requirements are
calculated in the same way as planning using a static target stock.
If you define a safety stock, the system checks if the stock has fallen below the safety stock. If you run the planning transaction online, the system displays
the requirements calculated and you can change them as required.
Generation of Follow-On Documents

After requirements have been determined, the system then generates sales orders with the order type TAV as follow-on documents. You have to start this
program manually on the screen for displaying requirements. You also have the option of carrying out this operation in a test mode.
During follow-on document generation, the system rounds off the quantity optimizing, which can lead to the quantity required being changed. The quantity
actually replenished is the requirement quantity after it has been rounded off. After a sales order has been generated, the stock figure for the customer
concerned increases by the quantity of the sales order.
The sales order is transferred to the customer by EDI in the form of an order acknowledgment (message type ORDRSP with the message variant VMI ). In
the standard system, order acknowledgments are generated for sales orders as messages of the type BAV0 . You must create the required condition records
for this.
Replenishment monitor
You can configure the general control parameters of Replenishment so that the results of the replenishment run are updated on the database. If you activate
updating, you can display the results of Replenishment in the Replenishment monitor.
Each time you execute the program for planning replenishments, the system stores the replenishment run under an internal number. The transaction can be
identified via this number in any subsequent analyses in the replenishment monitor. The results are divided into three categories (successfully processed,
workitem created, containing errors). Each category contains information on how the items were processed (for every combination of customer and article).
1.2.4.3.1 Customer Replenishments
Use
You can use this process to plan replenishments for customers using vendor-managed inventory (VMI).
Vendor-managed inventory (VMI) is one of the strategies aimed at enhancing the efficiency of the supply chain under the umbrella of Efficient Consumer
Response (ECR). VMI is a service that manufacturers offer retailers, whereby manufacturers take over the task of replenishing their products at retail outlets.
Prerequisites
The process is based on customer stock and sales data. The customer must have sent you this data beforehand, and it must be available in your system.
Data can be transferred to your ERP system using the EDI messages PROACT, WPUBON (from POS systems) and WPUUMS (from POS systems). You
can also maintain customer stock and sales figures manually in the system.
If the target stock is to be based on future sales (dynamic target stock), you first have to forecast the sales data.
Procedure
1. You plan replenishments either manually (online) or in the background (in batch) for selected customers and articles.
2. The system determines those articles requiring replenishing and calculates the replenishment quantities using the stock and sales data.
3. If you have triggered replenishment manually, you can change the replenishment requirements. You also have the option of carrying out replenishment in
a test mode.
4. The system passes on the replenishment quantities for further processing, and sales orders are created. The system can, if required, also round off
order quantities.
5. The replenishment stock figure is corrected in line with the document quantities (rounded figures).
Result
The replenishment planning run results in sales orders that you transfer to the customer by EDI in the form of an order acknowledgment.
1.2.4.3.2 Displaying Transferred Stock and Sales Data
Use
If a customer has sent you stock and sales data from their site by EDI, you can use this procedure to display the IDocs received.
Procedure
1. On the Sales Data from Customer: Selection Screen , enter the customer and/or the customer number for the goods recipients (your customer plants).
2. Execute the program.
The result list contains two levels. The header entry stands for each IDoc received. The items of the result list contain the sales and stock data contained in
the IDoc.
You can display the list using the list viewer, enabling you to use all the scrolling and sorting functions offered.
1.2.4.3.3 Analyzing Customer Stock and Sales Data

Use
You use this procedure to display and analyze sales and stock data sent to you by customers. The analysis is based on information structure S130 contained
in the standard system. This information structure contains information on the quantities sold of normal stock and of promotional stock at article, goods
recipient, merchandise category, and week level.
Procedure
1. On the Sales Data from Customer: Selection Screen enter the selection parameters. You may want to narrow down your selection to particular
customers, for example.
2. Run the analysis.
3. The result of the analysis is displayed. This screen offers you the full SAP standard analysis functionality. You can, for example, switch from drilling
down at ship-to party level to period level, run ABC analyses or compare different ship-to parties.
4. If necessary, you can save the specific version of your analysis so that you can display it later on (via Sales data anal. Get selection version).
1.2.4.3.4 Customer Replenishments Planning
Use
You can plan replenishments as follows:
manually
in the background
Procedure
To plan replenishments manually, proceed as follows:
1. Choose Logistics Sales and distribution Sales Order Customer replenishment Replenishment planning Execute .
2. On the Customer replenishment (VMI) screen, enter a customer or a customer group. Narrow down your selection further by materials and material
groups.
3. Choose Program Execute to obtain a list of replenishment requirements for each selected customer(s). You can call the overview of the
replenishment requirement by selected customer.
4. To change quantities, proceed as follows: A window appears detailing stock levels and the resulting replenishment requirements. Change the
replenishment requirements as required.
5. ChooseReplenishment requirements Generate follow-on document.The system saves the quantities and generates sales orders. You can also
call this function in a test mode.
6. You can then branch to the Replenishment monitor screen or the parameter overview screen. Here you view the errors, the workitems created and
the generated documents. On the parameter overview screen, to obtain this information first click on the ID of the replenishment run. If you called the
replenishment run using the test mode, you can generate follow-on documents from the replenishment monitor.
If you run the program in the background, this must be scheduled as a job in the system. If the system runs inbound processing for POS data or for customer
stock and sales data, this must be complete before replenishments can be planned.
1.2.4.4 VMI: Generating POs for EDI Order Acknowledgments
Use
An order acknowledgment received by EDI results in a purchase order being generated in the receiving system. A customer can use this function, for example,
to obtain information on sales orders that the vendor generated by planning replenishments for the customer. A purchase order is generated in the customer’s
system, the “opposite” of the sales order generated by the vendor.
The number of the sales order is entered in the purchase order as a reference. The system then sends a change message to the vendor indicating the
purchase order number generated in the customer system.
Prerequisites
On the vendor maintenance screen, you have to maintain the relevant purchasing organization data for the vendor by choosing Environment
Vendor order entry.
Vendor field
This is where you enter the internal number under which the vendor is managed in your system.
Customer (sold-to party) field
This is where you enter the external sold-to party number under which your company is managed as a customer in the vendor system.
You assign a purchasing organization and purchasing group to a particular combination of vendor and sold-to party in the details data. The
purchasing organization and purchasing group must be known when you create a purchase order. These do not, however, appear in the IDoc. This
is why the system determines them from the organizational assignment data when the IDoc is received.
The vendor can also send an external goods recipient number under which a site in your company is managed at the vendor's. For the system to
be able to convert this number when an IDoc is received to an internal site number, you enter the external number in the Customer (goods
recipient) field and the internal number of the site to receive the goods in the details data.
You can also specify the purchasing document to be used when a purchase order is created for the vendor. If you do not enter any purchasing
document type, the system uses that defined in Customizing for the creation of a purchase order online.
You must select the indicator allowing the vendor to enter purchase orders in the Purchasing data of the vendor master record of the vendor sending the
order acknowledgment .
An RP type must be entered in the site data for the article. This RP type must be assigned a “planning by an external system” planning method.
You must create purchasing information records for the articles and vendor concerned. You can also enter the vendor article number in the purchasing
information records, thus allowing your system to identify and convert the number if the vendor IDoc only contains the vendor article number.
Features
This function processes IDocs of the message category ORDRSP and message variant VMI . Before purchase orders are generated, the system calls the
user exit EXIT_SAPLWVMI_003 via which you can change the data of the inbound IDoc.
This enables you to convert vendor article numbers to the article numbers you use as you require. If a purchase order cannot be generated, because the data
is incomplete, for example, the system triggers a workflow.
For the system to transfer the purchase order number to the vendor system after the purchase order has been generated, an IDoc of the message category
ORDCHG is used with the message variant VMI . The system only sends this message if you maintained a partner profile for this message category.
1.3 Invoice Verification

Use
It is the task of Invoice Verification to check the accuracy of invoices received from vendors with respect to contents, prices, and arithmetic. An important
activity involves matching up invoices with purchase orders or goods receipts.
Logistics Invoice Verification is independent of Financial Accounting. This allows you to enter all the data in an original invoice at the location of the logistics
system and use a separate system for Financial Accounting.
Logistics Invoice Verification has been especially developed for the requirements of retailers. SAP Retail also comprises a conventional invoice verification
component. For technical reasons, however, certain key requirements, such as distributed systems and mass data processing, cannot be implemented in the
conventional invoice verification component.
Integration
Invoice Verification uses the data entered previously in the Purchasing and Goods Receipt application areas and passes on documents created when an
invoice is posted to Financial Accounting, Asset Accounting and Cost Accounting.
Features
Invoice Verification tasks include:
Entering invoices and credit memos that have been received
Checking the accuracy of invoices with respect to contents, prices, and arithmetic
Executing the account postings resulting from an invoice
Updating certain data in the SAP system (for example, open items and article prices)
Checking invoices that were blocked because the details varied too greatly from the purchase order
Constraints
Invoice Verification does not handle the payment or the analysis of invoices. The information required for these processes is passed on to other departments.
When an invoice is posted, the system simply creates open items on the vendor account which are then cleared when Financial Accounting makes payment.
For more information on Logistics Invoice Verification, see MM -
Logistics Invoice Verification .
See also:
Background Processing: Invoice Verification
1.4 Calculating the Planned Delivery Time
Use
Use this function to calculate and change the planned delivery time. Using the documents in the system, the system calculates the number of days between
the order being placed with the vendor and actual goods receipt. You can also use the planned delivery times calculated by the system in the master data as
the planned delivery time.
By using this function you can achieve more efficient goods procurement from your vendor and therefore avoid overstock and out-of-stock situations.
Scope of Functions
Until now, manual maintenance of data for the planned delivery time took place in three different places in the system:
at vendor level
at material level
at purchasing info record level.
The values maintained manually here are, however, mostly based on past experience and can quickly become obsolete as the behavior of the vendor
changes.
You use transaction WPTDC to call the function Calculate the Planned Delivery Time by workdays or calendar days and:
1. calculate the planned delivery time.
To calculate the planned delivery time, the system determines the number of days between the order being placed with the vendor and the actual goods
receipt for a freely definable combination of vendor, plant, material, purchasing organization and vendor subrange.
2. change the date of the planned delivery time.
The function supports you in your decision of whether you want to keep the manually maintained planned delivery time or replace it with the calculated
planned delivery time. You can decide this for each individual value in the master data for the vendor, material and purchasing info record.
Note that by changing the planned delivery time you can affect procurement.
Example
You notice that you have been getting increasingly more out-of-stock situations in your distribution center recently for a certain article from a vendor. You
suspect that there is a discrepancy between the planned delivery time that has been entered in the system manually and the actual delivery time. Using the
function for calculating the planned delivery time you can determine exactly how many days have passed between placing the order with your vendor and
actual goods receipt. You compare the planned delivery time that has been entered manually with the planned delivery time calculated by the system. You
establish that the vendor now requires three days longer to make the delivery that the date entered manually for the planned delivery time. You decide to copy
the planned delivery time calculated by the system to the master data.
1.5 Subsequent Settlement
Use
This component permits one-time or periodic settlement accounting with regard to conditions governing cumulative, end-of-period rebates.
If you use the Agency Business component, you can use these functions in purchasing both to settle accounts with vendors and with customers.
If, for example, you agree with your vendor or customer that certain conditions will not be paid with the invoice but – as long as a certain volume is reached
upon which you have agreed – not until the end of the agreed time, then you can create the agreement in the system. The system automatically updates the
relevant business volumes. Settlement with regard to such conditions takes place at predefined points in time.
You use this component if you and your vendors or customers agree to conditions of purchase that require subsequent (end-of-period rebate) settlement.
Integration
Required function: Required component:
Updating of cumulative business volumes at time of purchase order Purchase Orders
Updating of cumulative business volume at time of goods receipt Goods Receipt
Updating of cumulative business volumes at time of invoice verification Invoice Verification
Updating of invoiced sales at the time of vendor billing document, settlement Agency Business
request and customer settlement
Features
You can store arrangements entered into with your vendors or customers in the system. The arrangements involved can comprise two types of
condition: those requiring one-time settlement and those requiring periodic settlement. Both the validity period of the arrangement and the reference
magnitude (for example, quantity, value, weight, physical volume, or number of points) can be defined by the user.
The system automatically updates the business volume for the goods for the corporate unit involved when you save the documents.
You can still enter rebate arrangements after business volumes have already been recorded. In this case, the relevant business volumes are determined
and updated retrospectively.
At the end of the validity period of a rebate arrangement, or at the end of the agreed period, the system calculates the rebates payable with regard to
conditions that are due for settlement and creates a settlement list. Depending on the settlement type, the system either automatically creates a vendor
billing document or a sales invoice.
Interim settlement is possible at any time for both rebate arrangements requiring one-time settlement and those requiring periodic settlement.
If the results of your cumulative business volume update differ from those of your business partner, you can compare and reconcile the two sets of
figures and carry out settlement accounting on the basis of an agreed value.
Constraints
Conditions due for settlement immediately are settled as soon as invoices are received, or once payment has been made. These are therefore not discussed
here.
You can process business volume data from customer billing documents using the SD volume-based rebate.
Performance
To improve performance in application components other than SAP Retail that the subsequent settlement accesses, you can make global settings for each
client in Customizing for subsequent settlement:
You can switch off the entire subsequent settlement.
You can switch off individual checks for the updating of business volume and archiving.
See also:
BC – Workflow Scenarios for the Applications: Settlement of Rebate Arrangements in Purchasing (MM-PUR-VM)
Conditions
Agency Business
Background Processing: Subsequent (End-of-Period) Settlement
1.5.1 Subsequent Settlement Procedure
Use
This process description explains the complete business cycle of Subsequent Settlement.
Process Flow
The following graphic illustrates the individual phases of Subsequent Settlement. All the functions except Business volume comparison and Final
settlement occur repeatedly during the validity periods of the conditions.
Negotiating With the Arrangement Partner

You generally negotiate prices with your business partners at least once a year. You can set the prices for individual articles directly, or discuss end-of-period
rebates for one or more articles. You settle end-of-period rebates with the arrangement partner (vendor or prior vendor, for example) on the basis of the
business volume, sales, points, etc. achieved.
Creating/Maintaining Rebate Arrangements
You enter rebate arrangements (together with the conditions for subsequent settlement) in the system so that automatic settlement accounting can take place
on the agreed dates.
See Rebate Arrangements in Subsequent Settlement
Updating Business Volume
Within the validity period of each rebate arrangement, the system continually updates the business volumes (expressed as values, quantities, weights,
physical volumes, and points) for the relevant areas of application for each condition. The updated cumulative business volume data serves as the basis for
settlement accounting.
The business volume data can be updated on the basis of data from Pos, goods receipts, or verified invoices. The conditions determined during price
determination in the purchase order are valid here. These conditions are evaluated at goods receipt or during invoice verification, and trigger the updating of
cumulative business volume.
Business volumes from vendor billing documents and settlement requests are updated when the documents are released to Accounting.
See Business Volume Update in Subsequent Settlement
Comparing Business Volumes
If you have agreed with your business partner to compare and reconcile your respective cumulative business volume data, you carry out this process prior to
final settlement. If the values you and your business partner determine are different, you negotiate a value acceptable to both. This agreed business volume
figure then serves as the basis for final settlement.
See Business Volume Comparison in Subsequent Settlement
Settlement Accounting
At the end of the validity period of a rebate arrangement, or at the time of partial settlement accounting for a period-specific arrangement, the system
calculates the rebates payable with regard to conditions that are currently due for settlement and creates a settlement list. In this process, system takes the
cumulative business volume data not included in previous settlement accounting into consideration. The amounts payable thus determined are automatically
posted in Financial Accounting according to the settlement type.
You can carry out interim settlement accounting at any time for rebate arrangement conditions for which settlement accounting has not yet been effected.
Rebate income that is settled as a result is then offset against the amounts calculated as being due at the time of partial or final settlement accounting.
See Settlement Accounting in Subsequent Settlement
Archiving Rebate Arrangements
Rebate arrangements and all associated documents can be archived. You can store all the relevant data in an archive, and access this again as and when
needed. To ensure data consistency and traceability, all index files are archived together. A deletion program is also available.
For further informatio, see Archiving of Rebate Arrangements .
1.5.2 Rebate Arrangements in Subsequent Settlement
Use
A rebate arrangement groups together conditions requiring subsequent (end-of-period rebate) settlement which are valid over a certain time period (for example,
a fiscal year) and are due for settlement at the same point in time within this validity period.
Features
Arrangement type
Each arrangement is assigned to a certain arrangement type (for example, incentive rebate). Arrangement types are defined in Customizing and contain
general information, such as the following:
Default values (such as the date that is pre-set as the start of the validity period when an arrangement is created)
Arrangement calendar
Settlement calendar
Settlement type (debit-side or credit-side)
Permissible condition types and their areas of application (such as purchasing organization or site)
Settlement partner (vendor or customer)
Extending rebate arrangements
Frequently, arrangements providing for the payment of end-of-period rebates run for a long time or indefinitely. As a result, you can have the system
automatically adopt a rebate arrangement that you created for one calendar year (for example) as a rebate arrangement for the next calendar year.
Caution
You should not enter arrangements with long validity periods (for example, up to 31.12.9999), but instead use the mechanism for extending arrangements.
This ensures that arrangements are archived after a specific period, which reduces system load.
The period of extension is flexibly controlled via the arrangement calendar. Among other things, this facilitates statistical comparisons of a number of years.
Rebate arrangement partners
The partner concept enables you to record the relevant contact person for each rebate arrangement in the system. In particular, you can record who is
responsible for the individual rebate arrangement and who negotiated the conditions of the arrangement.
There are three types of partner:
Vendors
Own employees (with HR master record)
Contact persons (typically condition granters, only in Retail systems)
See also Business Partners
Arrangement texts
For each rebate arrangement and each condition you can enter texts that provide additional information, such as the meeting in which the agreement was
reached.
Settlement accounting
Rebate arrangements are subdivided into arrangements that require once-only settlement and those that require periodic settlement.
Settlement accounting for the former is carried out as per the validity end date of the arrangement.
Settlement accounting for the latter is carried out at certain points in time, as partial settlement or final settlement, according to the periods specified in
the settlement calendar.
In both cases, once settlement accounting has taken place, an indicator is set confirming that settlement has been effected for the conditions of the
arrangement. Condition records that have been settled cannot be changed.
Interim settlement can be carried out for both rebate arrangements requiring once-only settlement and those requiring periodic settlement. In this case,
settlement accounting extends to those conditions of an arrangement that would not otherwise be due for settlement at this time (because either the end date
of the arrangement or the end date of the next period has not yet been reached). In this case, the settlement indicator is not set: the conditions remain active
and are taken into account in the next partial or final settlement.
Note
If final settlement is to be carried out at the end of your business partner’s fiscal year, the validity period must correspond to this fiscal year. You can
achieve this by using suitable arrangement and settlement calendars.
1.5.2.1 Rebate Arrangement Processing (Vendor)
Purpose
This process allows you to create rebate arrangements by grouping together conditions requiring end-of-period settlement agreed with a "condition granter" that
are valid within the same overall timeframe and which are due for settlement at the same points in time.
Vendors may agree to refund a certain portion of the purchase price to purchasers in the wholesale/retail industry on condition that a certain quantity or value
of goods is bought (incentive rebates), that payment is effected promptly, or that promotional activities are carried out, for example. End-of-period refunds of
(retrospective discounts allowed on) part of the total spend with a certain vendor may also be payable as the vendor’s contribution towards disposal costs
incurred by retailers and wholesalers (in connection with packaging, waste materials returned such as spent batteries, etc.). If a vendor agrees to enter into an
such an arrangement with you, he is regarded in the SAP System as "granting conditions".
Conditions can be divided into two groups: those having immediate effect based on individual invoice dates, and those requiring "subsequent" settlement
(retrospective settlement at the end of a certain period).
Conditions having immediate effect are taken into account immediately in the vendor invoices or at the time of payment of the latter (and therefore do not
form part of this module).
Conditions having subsequent effect have to be taken into account at a later date : that is, some time after the submission of an invoice relating to an
individual purchase transaction. In this case, settlement is based not on individual transactions but on the total volume of purchases - expressed in money or
quantity terms - over a period. This is what is meant by "subsequent settlement."
You can enter rebate arrangements negotiated with the "condition granter" (comprising the agreed conditions involving subsequent settlement) in the system.
Later, settlement with regard to such arrangements can be effected automatically, when payment becomes due. (Process: settlement accounting for
conditions requiring subsequent settlement.)
Rebate arrangement processing in the SAP System provides the following options:
Conditions apply on the one hand to goods/merchandise and on the other to organizational units of an enterprise (area of application).
If a condition applies to several articles that do not belong to the same vendor sub-range, you can assign these articles to a "settlement group" for joint
processing.
Conditions relating to a group of articles (a vendor sub-range or a settlement group, for example) are created with a "settlement article." The latter serves
to facilitate any necessary conversions between different units of measure.
A volume rebate arrangement can contain scaled or non-scaled conditions/main conditions and period conditions.
Furthermore, you can extend the validity of such an arrangement to cover a longer time-span or "until further notice". For example, an arrangement
created for one calendar year can be automatically replaced by a new, identical one that is valid for the following calendar year.
Process Flow
1. You first choose an arrangement type. This determines the payment method, default values for validity periods, the permissible condition types, and key
combinations, for example. It is also used to assign the settlement and arrangement calendars.
2. You then enter the condition granter and define the validity period of the rebate arrangement.
3. You enter the conditions that make up the arrangement. In the case of arrangements requiring periodic settlement, you also enter the period-specific
condition records (covering the individual periods within the overall timeframe of the arrangement).
4. If required, you define rebate scales for the conditions, together with the relevant validity periods.
5. You specify whether a business volume comparison and agreement process is to take place (in order to identify and reconcile any discrepancies
between your company’s and the vendor’s figures) prior to final settlement accounting with regard to the rebate arrangement.
Notes and Remarks
Before you set up a volume rebate arrangement in the system, the Subsequent settlement indicator must have been set for the condition granter in the
vendor master record at the desired purchasing organization level.
For conditions relating to a group of articles, you must make sure that a "settlement article" has been maintained in the system. This is used to carry out
any necessary conversions between different units of measure and may also be used for billing rebate income due. The settlement article is entered in
the arrangement.
The ongoing business volume update process is based upon certain important information from the conditions, such as the area of application (condition
relates to goods/merchandise or to organizational units of an enterprise), and settlement frequency. This information cannot be changed once the
arrangement has been created in the system.
In the case of broker processing, ensure that an access sequence for broker processing has been assigned to the condition type (in Customizing).That
is to say, the condition type must include accessing of the prior vendor (original, or supplier’s, supplier).
You will find details on the volume of business done with a vendor in the lists Detailed statement (e.g. of purchase orders or invoices received) and
Statement of statistical data as well as in the Standard analysis for subsequent settlement accounting. You will find these lists in the Subsequent
settlement menu .
Caution
You create arrangements for a promotion via the Promotion menu.
1.5.2.1.1 Creating a Rebate Arrangement
Procedure
1. On the Create Agreement screen, enter the desired arrangement type and choose Goto Organizational data .
The Organizational data screen appears.
2. Enter the desired organizational data and pressENTER .
The Arrangement overview screen appears.
3. Enter descriptive and control data relating to the arrangement, such as:
Description of the arrangement
Condition granter, currency
Validity period
Control data
You can, for example, define that business volume has to be compared with the vendor before partial or final settlement is made. The system suggests a
value from the vendor master.
4. Choose Goto Arrangement partner to enter the name of a person who is responsible for the rebate arrangement, for example. Partner roles may
have been defined as mandatory roles in the partner schema for the arrangement type (Customizing). Return to the previous screen.
5. Choose Goto Conditions to enter the conditions belonging to this rebate arrangement.
Note
If the settlement type is debit-side settlement at purchasing organization level , the Debit-side settlement level screen appears, with the appropriate
mandatory entry fields (for example, the sales organization). Otherwise, the system goes directly to the next screen.
If the settlement type is debit-side settlement at site level , the necessary data can be determined automatically from the master data if the latter has
been maintained.
6. If several condition types or key combinations exist, a box showing the valid condition types and key combinations now appears. Choose the entry for
which you wish to create conditions. Click Choose to call up the entry screen for conditions.
If there is only one valid condition type , the entry screen for conditions appears immediately.
7. Enter one or more main condition(s).
Note
If a settlement calendar has been defined for the rebate arrangement, period conditions are created automatically. If the calculation rule for the period
conditions is the same as that for the main condition, the Amount and Unit are adopted. Otherwise, these fields are set to zero and must be
remaintained manually. The Provision field in the main condition is simply a suggested value for period conditions that have not yet been created. When
provision is later created when purchase orders are created, the provision of the valid period condition is used.
8. The following options are available for processing a main condition:

You can process the details . To do so, select the main condition and then choose Goto Details . On the detail screen for the main condition, you can
then enter a settlement article, for example.
You can specify scale levels . To do so, select the main condition and choose Goto Scales . If desired, you can enter a currency unit that differs
from the arrangement currency.
If a settlement calendar has been assigned to the rebate arrangement, you can define the period-specific conditions . To do this, select the main condition
and choose Goto Period conditions . See Processing Period-Specific Conditions .
9. Save your rebate arrangement.
1.5.2.1.2 Creating a Rebate Arrangement Using the Referencing

Technique
Use
If you wish to adopt data from an existing arrangement, you can reference the latter when you create a new arrangement.
Prerequisites
The arrangement type in both cases must be identical.
Note
You cannot use this function to extend an arrangement (for example, to cover the following year). A separate transaction (Manually extending a rebate
arrangement) is available for this purpose.
Procedure
To create a rebate arrangement by referencing an existing one, proceed as follows:
1. On the Create Rebate Arrangement screen, enter the desired arrangement type and choose Arrangement Create with reference .
The box for entering the reference arrangement appears.
2. Enter the ID of the rebate arrangement you wish to reference, specify the new validity period, and copy.
The arrangement overview screen appears. The data from the reference arrangement is preset in the new arrangement.
3. Make any necessary changes to the data. If you have used an arrangement requiring periodic settlement as a reference, you must enter a new, unique,
external description.
4. Choose Goto Conditions to change the conditions of the arrangement. If necessary, change the detail data, the scale levels, and the period-specific
conditions. See also Processing Period-Specific Conditions .
1.5.2.1.3 Extending a Rebate Arrangement Using a Report

Use
You can use this procedure to extend a rebate arrangement. In this procedure, you create a new rebate arrangement referencing the old arrangement.
Prerequisites
A prerequisite for extending a rebate arrangement is that an arrangement calendar has been assigned to the relevant arrangement type in Customizing.
Note
Note that a rebate arrangement must be extended in good time (before the creation of the first purchase order for the new arrangement period), so that the
business volume data can be recorded correctly.
If an arrangement is not to be extended any further, delete the arrangement calendar from the last valid arrangement by choosing the function Remove
arrangement calendar from the Extras menu during rebate arrangement maintenance. If the rebate arrangement is later to be extended after all, you can
restore the arrangement calendar to the arrangement in the same way.
Procedure
To extend the validity of an arrangement, proceed as follows:
1. On the Extension of Rebate Arrangements (Purchasing) screen, enter the desired selection criteria and specify which details you wish to see in which order
in the list output.
2. Run the program. You can decide whether or not the program is to be run in the background and whether you wish to have the list of results printed out.
If the extension has been successful, the list will contain the appropriate messages.
Note
You can display the extensions of a rebate arrangement in maintenance or display modes via Goto Extended arrangements . This function is also
available on the Business volume comparison screen.
1.5.2.1.4 Manually Extending a Rebate Arrangement
Use
You can use this procedure to manually extend a rebate arrangement. In this procedure, a new rebate arrangement is created and linked to the old
arrangement. In contrast to extending an arrangement using a report, in the manual procedure you are able to make changes to the rebate arrangement before
saving it.
Prerequisites
A prerequisite for extending a rebate arrangement is that an arrangement calendar has been assigned to the relevant arrangement type in Customizing.
Note
Note that a rebate arrangement must be extended in good time - before the creation of the first purchase order for the new arrangement period, so that the
business volume data can be recorded correctly.
If an arrangement is not to be extended any further, delete the arrangement calendar from the last valid arrangement by choosing the function Remove
arrangement calendar from the Extras menu during rebate arrangement maintenance. If the rebate arrangement is later to be extended after all, you can
restore the arrangement calendar to the arrangement in the same way.
Procedure
To extend the validity of an arrangement, proceed as follows:
1. On the Extend Agreement screen, enter the rebate arrangement to be extended and press ENTER .
A dialog box containing error messages and warnings may appear. The overview screen for the new rebate agreement is then displayed.
2. Make the necessary changes.
3. Save the new rebate arrangement.
Note
You can display the extensions of a rebate arrangement in maintenance or display modes via Goto Extended arrangements . This function is also
available on the Business volume comparison screen.
1.5.2.2 Retrospective Creation of Rebate Arrangements
Use
In the normal course of the process chain, arrangements are created before the documents relevant to business volume. During price determination for a
document item, the system determines the condition records and includes these in the document conditions. On the basis of the settings in the document
conditions, the relevant cumulative business volumes are then updated in the information structures of the LIS.
In some cases, however, it is not possible to create the rebate arrangement in good time. This may be due to one of the following reasons:
Annual negotiations with the vendor do not take place until April. However, the agreed conditions requiring subsequent (end-of-period) settlement apply
retrospectively (i.e. from the start of the year).
The programs for Subsequent Settlement are activated during current business operations.
In both cases, documents already exist in the system, and a rebate arrangement whose condition records are not included in the document conditions will thus
be entered subsequent to the creation of these documents.(If the rebate arrangement had been created at the right time, the arrangement conditions would
have been included in the purchasing document conditions.)
You can ascertain whether a rebate arrangement was created retrospectively by looking at its creation date (see Rebate arrangement maintenance.
Extras Status information ). For condition records - especially for period-specific condition records - there is a corresponding indicator in the detailed
view, which you can also change if necessary.
A rebate arrangement is regarded as having been created retrospectively if its validity period begins prior to or on the same day as its creation. If this is the
case, relevant documents may already exist in the system.
Likewise, a condition record is regarded as having been created retrospectively if its validity period begins prior to or on the same day as its creation. Only a
retrospectively created rebate arrangement can contain retrospectively created condition records.
Example
Rebate arrangement 1 Valid from 01.01. – 31.12.,
Entered on 03.01, 10:00
Monthly period-specific conditions (periodic partial settlement)
Business volume. updating as per invoice receipt
Purchase order 4500000010, entered on 10.02.
Invoice no. 5000000100, document date 10.03.
Invoice no. 5000000140, document date 02.04.
Purchase order 4500000020, entered on 01.03., 09:00
Invoice no. 5000000120,
Purchase order 4500000030, entered on 03.06.
Invoice no. 5000000130
In the above example, rebate arrangement no.1 was created at 10:00 on 03.01. Since its validity period start date is 01.01, it is a retrospectively-entered
arrangement. The Retrospective entry indicator is set for the period-specific condition records for the months of January, February, and March.
The cumulative business volume update for purchasing document no. 4500000030 is carried out in the normal way (in this case, following invoice receipt).
This is not possible for documents 4500000010 and 4500000020, because their document conditions do not include a condition record for rebate
arrangement no. 1. The business volume update process cannot therefore be triggered in these cases.
Activities
Business volumes are updated in the normal way if they were entered after the arrangement was created. However, retrospective determination and updating
of the relevant business volumes is necessary for those documents that were entered prior to the creation of the rebate arrangement.
For information on how to determine the missing vendor business volumes for retrospective rebate arrangements and condition records, please see Business
Volume Updating in Subsequent Settlement .
1.5.3 Conditions in Subsequent Settlement
Use
A condition is an individual stipulation within a rebate arrangement. Conditions apply on the one hand to goods or merchandise (for example, vendor
assortment, vendor sub-range, merchandise category, article), and on the other to the organizational units of a corporate enterprise (such as sites or
distribution centers), referred to in the following as the "areas of application". If a condition applies to several articles that do not form part of the same vendor
sub-range, these articles can be assigned to a single "settlement group".
Features
Conditions can be described as follows:
Each condition specifies a certain rebate. This consists of the amount (for example, fixed amount or percentage) and the unit of rebate of the amount
(for example, $, %).
Each condition is assigned to a condition type. The condition type is defined in Customizing and determines the basic characteristics of a condition,
such as the reference magnitude and the calculation rule. Via the condition type, you can also specify whether or not a provision for accrued income is
to be set up.
Note
In the case of scaled conditions, the reference magnitude defines how the scale is to be interpreted. The scale can relate to a quantity, a value, a weight,
a physical volume, or a number of points.
The calculation rule specifies how the rebate payable with respect to a condition is to be calculated. The rebate can be a fixed amount or a percentage.
The amount can relate to a quantity, a value, a physical volume, a weight, or a number of points.
Via provisions for accrued income you determine whether anticipated rebate income is to be taken into account in the current valuation of an article (that
is to say, whether the moving average price in the article master record is adjusted at the time a goods receipt is posted for a purchase order whose price
determination process takes account of a provision-relevant condition).
You can flag condition types as independent of business volume. An example of this may be condition types that are used to settle promotional deals. Only a
fixed amount is allowed as a calculation rule for these types of conditions. You cannot work with provisions for accrued income, as business volume is not
updated. Conditions that are independent of business volume should not be entered in calculation schemas for purchase orders, vendor billing documents or
single settlement requests.
Each condition can be specified in a different currency - even within the same rebate arrangement. The currency in which settlement is to be carried out
(the settlement currency) is entered in the rebate arrangement.
A condition can be scaled or non-scaled. The rebate payable under non-scaled conditions remains constant (that is, it is independent of the quantity or
value purchased etc).
For information on scaled conditions, please see Scaled Condition in Subsequent Settlement .
Settlement for condition can be carried out periodically. In the case of conditions subject to periodic settlement, the planned settlement dates for each
period are determined via the settlement calendar. The dates defined in the calendar determine the validity periods and thus the due dates of the
conditions. Similarly, the date for effecting a final settlement (last settlement within the validity period of an arrangement) can be predefined if desired.
For information on conditions requiring periodic settlement, please see Period-Specific Conditions in Subsequent Settlement . Each condition can apply to
certain goods or merchandise on the one hand, and to certain organizational units of a corporate enterprise on the other. You determine which of the two a
certain condition applies to via the key combination of the associated condition table (condition tables are defined in Customizing):
Goods-related
The condition applies to an article, a vendor sub-range, a merchandise category, a settlement group or to the entire vendor assortment.
Corporate-unit-related
The condition applies to a site or a purchasing organization.
A settlement group is a grouping of certain articles to which the same rebate arrangements or conditions apply. The settlement groups are stored in the info
record of the vendor for the article.
For conditions that relate to a group of articles (for example, to a vendor sub-range or a settlement group) you must ensure that a settlement article is
maintained in the system (on the detail screen of the conditions). This is needed by the system to perform conversions between units of measure and, in
some cases, to create a billing document in the course of settlement accounting.
See also:
ISR – SAP Retail: Conditions
1.5.3.1 Main Conditions in Subsequent Settlement
Definition
The main condition is the condition agreed with the settlement partner for the purposes of final settlement in the case of periodic arrangements.
Use
When you create a rebate arrangement, you define the main conditions at the highest level. All main conditions can have the same validity period. You enter
the rebate payable for each main condition.
Example
The buyer has negotiated an end-of-period rebate of $1 for each item of a particular article purchased.
Integration
Final settlement for a rebate arrangement is always carried out using the main condition. A main condition can be scaled and/or subject to periodic settlement.
Periodic settlement is only possible if a settlement calendar has been assigned to the arrangement.
1.5.3.2 Scaled Conditions in Subsequent Settlement
Definition
Scaled conditions specify a series of rebates that vary according to different total volumes of purchases made over a period (expressed as a quantity, value,
or number of points). Scaled conditions consist of one or more scale levels.
Use
Each scale level consists of a scale value and a rebate that depends on this value:
The scale values of a condition can be defined via the business volume (expressed as a quantity or dollar value). The unit of the scale value (for
example, quantity, weight, physical volume, points) is defined in Customizing for the condition type in the Reference magnitude field. The value in
combination with the reference magnitude is also referred to as the scale basis .
The rebate consists of the scale amount (for example, fixed amount, percentage) and the unit of rebate of the amount (for example, $ or %). The amount
is calculated for a quantity, a weight, a physical volume or a number of points, for example. This unit is termed the condition basis and corresponds to
the reference magnitude.
Example
Scale level Scale basis Condition basis
First scale level From 1,000 (Scale value) pieces (Reference 1 (Scale amount) dollar (Unit of rebate) per piece
magnitude)
Second scale level From 2,000 (Scale value) pieces (Reference 2 (Scale amount) dollar (Unit of rebate) per piece
magnitude)
The following scaled conditions are possible:

From-scales
From 100,000 pieces 2%
From 200,000 pieces 3%
With business volume of 500,000 pieces, at $1,000,000, income is 30,000.
To-scales
To 100,000 pieces 2%
With business volume of 500,000 pieces, at $1,000,000, income is $0.
Interval scales
With business volume of 500,000 pieces at $1,000,000, income of 2% of $200,000= $4,000 is granted for the first 100,000 pieces, and an income of 3% of
$200,000= $6,000 is granted for the next 100,000 pieces. There is no income for the remaining 300,000 pieces.
Integration
Prior to settlement accounting, the system determines the scale level that has been achieved by referring to the scale values, and then calculates the rebate
payable.
Rebates payable as fixed amounts can be determined directly.
Sums payable as percentages or per unit (for example, quantity, weight, physical volume, points), are calculated on the basis of the business volume
(expressed as a quantity etc. or dollar value) done with the business partner in the relevant area of application in accordance with the desired calculation rule.
1.5.3.3 Period-Specific Conditions in Subsequent Settlement
Definition
Period-specific conditions are used for partial settlement in the case of periodic arrangements.
Use
If conditions are settled periodically, the main condition defines the overall validity period. The validity periods for the individual period-specific conditions must
fall within the validity period of the main condition. When determining prices in the documents, the system uses only the period-specific conditions.
Different conditions can be entered for each period. The unit of rebate of the period-specific conditions can differ from that of the main condition. For example,
settlement with regard to the main condition can be effected as a percentage, whereas settlement for the period-specific conditions can be effected as a fixed
amount in dollars. This is configured via the calculation rule in Customizing for the condition type. When maintaining conditions, you can assign a different
calculation rule to the period-specific conditions.
Settlement Calendar
The periods in the period-specific conditions correspond to those in the settlement calendar that is valid for the rebate arrangement. For example, only monthly
period-specific conditions are created in the case of monthly settlement. These periods cannot be changed once the rebate arrangement has been set up.
Assumed Values
In the case of scaled conditions, the use of period-specific conditions allows settlement to be effected using assumed values if desired. These assumed
values can represent empirical figures or estimates. Thus the assumed value can be used for the purposes of partial settlement in the course of the fiscal
year, it is not necessary to take into account which scale level has actually been reached on the basis of the business volume achieved to date. This
approach permits a non-fluctuating rebate income to be generated as early as possible within the validity period of a condition.
Example
Scaled Condition
From $100 000 1%
From $200 000 2%
From $300 000 3%
From $400 000 4%
From $500 000 5%
Period-Specific Conditions
1. – 31. January: 3%
1. – 28. February: 3%
1. – 31. March: 3% etc.
Setting the period-specific conditions at 3% reflects the empirical value for the last few years. To date, purchases worth at least $300,000 have always
been made from this vendor each year. The advantage of this setting is that settlement is already effected on the basis of 3% over the first few months of
the year, even though the business volume does not reach the 3% scale level during this time.
Final Settlement with Respect to Period-Specific Conditions

In contrast to partial settlement within the validity period, final settlement with respect to period-specific conditions takes into account the total business
volume achieved over the period, even if partial settlement has already been effected with respect to the conditions in some cases. By taking total figures into
consideration, a higher scale level can be reached in the case of scaled conditions (and hence a larger rebate attained). The final sum payable is arrived at
after deduction of the rebates already paid in the course of the partial settlements.
In Customizing, you can specify whether final settlement should be effected.
1.5.3.3.1 Example of Final Settlement for Period-Specific
Conditions
Vendor 4711:
Main condition
Valid from 1 January - 31 December
From $100 000 2%
From $200 000 2%
From $300 000 3%
From $400 000 4%
Period-Specific Conditions
Quarterly settlement:
1. January – 31. March
1. April – 30. June
1. July – 30. September
1. Oct. – 31. Dec., 2% each
Volume of business done with vendor 4711:
January $25 000
February $20 000
March $29 000 2% = $1 480 (Partial settlement)
April $50 000
May $45 000
June $34 000 2% = $2 580 (Partial settlement)
July $23 000
August $20 000
September $38 000 2% = $1 620 (Partial settlement)
October $35 000
November $19 000
December $32 000 2% = $1 720
Jan. - Dec. $370 000 3% = $11 100 (final settlement for this year)
The results of the partial settlements are set out above. Final settlement takes into account the total volume of business done with (volume of purchases
made from) the vendor over the period as a whole. Since a total business volume of $370 000 was achieved, the third scale level (3%) is reached. The total
rebate earned thus amounts to $11 100 (3% of $370 000).
However, since partial settlements have already been effected during the year (in March, June, and September), the sum due in final settlement amounts to
$5,420 ($11 100 – $1 480 – $2 580 – $1 620 ).
1.5.3.3.2 Processing Period-Specific Conditions
Use
You can enter different rebates or refunds for individual periods.
Note
If settlement accounting has already been carried out for a period-specific condition, no further changes can be made with respect to this condition.
Procedure
1. On the Change Agreement screen, enter the rebate arrangement ID and press ENTER .
The arrangement overview screen appears.
2. Choose Goto Conditions and then the desired condition type.
The overview screen for the conditions appears.
3. Select the condition for which you wish to process the periods and choose Goto Period conditions .
The screen with the period-specific conditions appears.
4. You can choose a different calculation rule via Edit Other calculation rule . This enables you to determine in individual cases whether or not, for
example, final settlement is to be effected on the basis of the total money business volume and the partial settlements on the basis of quantity.
Note
When creating the period-specific conditions, you cannot enter a unit of refund that differs from that of the main condition if the calculation rule of the main
condition is the same as that of the period conditions.
To ensure data consistency, the unit cannot be changed after the rebate arrangement has been saved.
5. If you wish to process the amount of an individual period, enter the amount in the desired line.
If you wish to assign the same amounts to several periods , choose Edit Mass maintenance . In the following box, enter the condition amount. If
the condition type is provision-relevant, you can enter the amount of the provision (on the purchasing side, this relates to the rebate income that is expected).
1.5.4 Business Volume Updating in Subsequent Settlement
Use
During settlement accounting, the system uses the volume of business done with your business partner to determine the scale level, for example. In this
process, the system updates the business volumes (expressed as a money value in the rebate arrangement currency), and the purchased quantities, weights,
physical volumes, or points for each condition, depending on which data is required for settlement purposes. The money value of the business volume is
updated in all cases.
Prerequisites
If the cumulative business volume figures are updated at the time of the purchase order or the goods receipt, the tax code of the PO item must be known. You
maintain this in the info record or use the condition technique to set it.
Features
If different currencies or units of measure are used in a rebate arrangement (e.g. arrangement currency differs from scale currency and scale unit differs from
condition unit) the system records the business volumes in all currencies and units that occur. As a result, problems caused by exchange rate fluctuations or
missing conversion factors are avoided.
The following methods of updating are possible:
Updating at time of purchase order
Updating is carried out as at the delivery date. When you order an article from a vendor, the vendor’s conditions that are valid on the purchase order date are
used to determine the price of the article. The relevant condition type must be specified in the calculation schema for this purpose.
Updating at time of goods receipt
Updating is carried out as at the document date. The time-independent conditions of the PO or the results of a new price determination process (in the case of
prices for precious metals, for example) can be used as the basis for this. A new price determination process is always carried out at the time of goods receipt
if the GR date is specified as the pricing date category.
Updating at time of invoice receipt
Updating is carried out as at the invoice date. With regard to the value, you can elect to update using either the verified final invoice value or the PO data. In
this case, the scale and condition basis to be updated can be any level of the calculation (the net/net purchase price, for example).
In the case of subsequent debit, business volume is updated on a value basis only.
Business volumes from vendor billing documents and settlement requests are updated when the documents are released to Accounting.
Business volumes can also be updated for service items, but only on the basis of the associated PO items. This is not integrated with price determination for
the individual services. You can therefore only work with money values of business volumes. You can also use blanket purchase orders and invoicing plans.
Business is always updated from the invoice.
Business volumes that result from credit memos and invoices without reference to purchase orders in Invoice Verification cannot be taken into account in
Subsequent Settlement. The documents do not support price determination. Instead, you can use vendor billing documents.
Business volumes from consignment processes cannot be taken into account in Subsequent Settlement either, as, in these cases, invoices without reference
to purchase orders are created.
The general rule in the case of scheduling agreements with time-dependent conditions is that the price determination process is not carried out as the basis for
updating until the time of goods receipt. Under certain circumstances updating that is planned for the time of the purchase order may take place at the time of
goods receipt. Updating that is planned for the time of invoice verification may be brought forward to the time of goods receipt.
Updating takes place for each valid condition. In the process, the business volumes (expressed as dollar values and quantities) are cumulated separately for
the area of application (goods-related or corporate-unit-related conditions) of each condition, and for each site and each tax rate. If settlement is effected
monthly or more frequently, updating is carried out simultaneously for each settlement period. If settlement is carried out less frequently than monthly, the
business volumes are nevertheless updated on a monthly basis. This ensures that it is subsequently possible to generate monthly statistics.
The updating of business volumes is based on certain important information from the conditions, such as area of application and settlement frequency. For
this reason, you cannot change such information once a rebate arrangement has been created.
1.5.4.1 Purchase Orders and Price Determination in Subsequent

Settlement
Use
The purchase order is a prerequisite for the cumulative updating of business volume figures. This section explains the price determination process for a
purchase order and the how these functions interact with Subsequent Settlement.
Price determination for Agency Business documents is carried out in the same way.
Features
When a purchase order is created, the system carries out price determination. This process is based on the price calculation carried out for the article. The
calculation also defines which value is relevant to subsequent (end-of-period rebate) settlement accounting with respect to a condition (in the above example,
this is the net net purchase price, NNPP).
Within the framework of price determination, the system checks whether any conditions have been agreed with the relevant vendor for the article in question
(in the example: 5% discount and 1% surcharge) at the time of the purchase order. In this case, the valid conditions (4711) are taken into account in the
purchase order and displayed.
If a condition belongs to a condition type for which a provision for accrued income is to be set up (that is, the condition involves subsequent settlement), the
value of the provision (here: 1 % of 191.90 = 1.92) is displayed in the purchase order. In the case of condition types without provisions for accrued income, the
value "0" is shown against the condition.
For weight- and volume-dependent condition records, the gross or net weight or the physical volume must be maintained in the article master record,
purchasing info record, and/or the purchase order item, so that the system can access the condition record and update the business volume. In the case of
points-dependent conditions, the points conversion factor must be maintained in the purchasing info record or in the purchase order.
1.5.4.2 Updating Business Volume from Customer Settlement

Documents
Use
The document type customer settlement document used in Agency Business supports item-oriented price determination. Subsequent settlement takes these
customer settlement documents into account when updating the business volume.
A customer settlement document is used for the separate posting of debit side postings from a single settlement request. That means that debit side postings
no longer come from the single settlement request but are grouped together from the customer settlement document.
Customer settlement documents are created by copying the items from all single settlement requests which have not yet been transferred to customer
settlement documents. All single settlement request items for one customer are grouped together. The single settlement request has to be created within a
single settlement request list. They cannot be created individually.
Integration
Unlike posting lists, which also enable grouped separate debit-side posting, customer settlement documents contain item data. The document supports item-
oriented price determination in particular. Business volume and provisions for rebate income updates for use in subsequent settlement can no longer be made
in the single settlement request (no postings in Financial Accounting from this document), but instead have to be carried out from the customer settlement
request.
The expense settlement document which is also used in Agency Business does not take subsequent settlement into account when updating the business
volume.
Features
If a single settlement request is transferred to customer settlement documents, business volume update and posting of provisions for rebate income does not
take place for customer rebate-relevant document conditions (no customer posting altogether). When single settlement requests are transferred to customer
settlement documents, business volume update and posting of provisions for rebate income takes place using document conditions from the customer
settlement document. These can be identical to the document conditions of the settlement request or can be totally or partially redetermined. Note the copy
control when doing this. The system always redetermines condition records for subsequent settlement, however, to ensure consistency in the document data
and document conditions.
Subsequent settlement manages customer settlement documents under the new document category 60 . Subsequent business volume update is also
supported. Report RMEBEINA , transaction MEIA enables the document index S111 to be recreated for use in subsequent business volume update.
You cannot choose whether the system performs business volume update from the customer document conditions of the single settlement request or the
customer settlement document.
Activities
In price determination for the customer settlement document you can only use purchasing data (invoicing party, purchasing organization etc.), if you set the
Additional Item Data indicator in the billing type, because otherwise the system removes the condition records relating to purchasing fields when transferring
the single settlement request to customer settlement. Otherwise the document conditions for the fields in the document would be inconsistent.
The customer settlement document item does not have any fields such as invoicing party, purchasing organization etc. If necessary, the system looks these
up from the single settlement request. For performance reasons, you should only set this indicator if really necessary.
Item 1 in settlement request 1 is transferred to customer settlement document 2, item 2. The customer settlement document does not have any fields such as
purchasing organization and vendor at item level. This information is only saved in the header of the settlement request. If you set the Additional Item Data
indicator, the header of document 1 is read in the price determination for customer settlement document 2, item 2. The communication structure KOMK for
price determination of customer settlement document 2, item 2 is extended with the following fields.
MOVE KOMLFK-LIFRE TO KOMK-LIFRE
MOVE KOMLFK-EKORG TO KOMK-EKORG
MOVE KOMLFK-LIFRE TO KOMK-LIFNR
If you do not set this indicator, these three fields remain blank. Condition records that relate to these fields are removed when the customer settlement
document is removed.
If you need to copy extra fields, you can do this in user exit LWZRE001 , component EXIT_SAPLWLF0_001 or in the BAdI WLF_ADDITIONAL_DATA2 ,
method change_pricing_header .
Maintain the residence time for archiving for document category customer settlement.
If you want to use subsequent business volume update (generally for customer rebate arrangements) and documents for the customer could be affected, flag
the Document Index Active indicator in the customer master. Note, however, that setting this indicator increases the volume of data.
If necessary, an entry is created in document index table S111 each time an existing rebate-relevant access sequence that is used by at least one condition
type is accessed. The volume of data can become very large. Do not under any circumstances delete all the rebate relevant access sequences that are not
being used, for example, the access sequences delivered by SAP.
The indicator in the customer master is maintained at sales area level (Sales screen). For documents without a sales area, entries are always created (no
control function exits).
Note that this indicator is only valid for customer settlement documents. For single settlement requests (customer price determination) you need to specify
explicitly that the indicator needs to be taken into account in the central control table (report RWMBON21 , transaction WMN9 ).
The Document index indicator in the customer master also controls the creation of entries for customer price determination for single settlement requests.
The indicator for the vendor is only relevant for vendor price determination.
1.5.4.3 Business Volume Updating in Subsequent Settlement

(Process)
Purpose
When business volumes are updated, the total volume of business done with a business partner in a specified period is recorded. This value is needed in
settlement accounting.
Process Flow
1. During price determination for a purchase order is created, the system establishes which conditions apply to the purchase order in question.
2. When the vendor’s invoice is received, it is checked against the purchase order and the goods receipt.
3. If the incoming invoice is correct, the cumulative business volume data (values, quantities purchased, and so on) is updated by the addition of the data
from the invoice.
4. Credit memos received from vendors have a retrospective and reversing effect on the updated data in comparison with the corresponding invoices. The
areas of application and the validity periods of the conditions are taken into account. If, according to the condition type, a provision for accrued income
is to be set up, the appropriate posting is made at the time of goods receipt and the moving average price in the article master record is changed
accordingly.
In the case of articles with standard price, the articles stock data is not reduced. An offsetting entry is posted in the price difference account.
1.5.4.3.1 Example of Business Volume Update for a Condition
A rebate arrangement has been entered into with vendor 12345 with regard to the vendor sub-range XY. This is valid for the entire calendar year. When a
purchase order is created for article 22222 on Feb. 10, the system recognizes that article 22222 belongs to vendor sub-range XY, and that the rebate
arrangement 5 is valid at this point in time. When the vendor’s invoice created on the basis of this PO is subsequently released for payment, the cumulative
business volume data is updated as outlined above.
Updating is carried out for each condition at the level of vendor, site, and tax rate in the rebate arrangement currency and the unit of measure of the condition.
At the same time, the figures are cumulated separately for each settlement period. However, if settlement is effected less frequently than monthly, the update
data is still cumulated on a monthly basis. This ensures the availability of monthly statistical information.
1.5.5 Subsequent Updating of Business Volumes
Use
If you have entered arrangements or conditions retrospectively (see Subsequent Settlement: Retrospective Entry of Arrangements ), you must retrospectively
update the values for business volume achieved, so that the system takes all business volume into account during settlement accounting.
Prerequisites
A prerequisite for the subsequent update of business volumes is that the Subsequent settlement index indicator is set for all vendors concerned. If this
indicator is not set, business volumes can only be compiled for documents for which an update has been carried out in the past ( Recompilation of Business
Volume Data and Incomes ).
In order to carry out the retrospective update of business volumes, the system must be able to efficiently access all documents that may be relevant to a
retrospectively entered condition record. This is done using LIS information structure S111 , the "Document index".
In the data browser ( Tools ABAP Workbench Overview Data browser ), you can check which documents are contained in the document index.
Use the following procedure:
1. Enter table S111 and choose Table contents .
2. In the Document category field (BLTYP) enter value 01 (purchase order/scheduling agreement), 30 (vendor billing document) or 40 (settlement request),
and in the Version field (VRSIO)enter LIS version 000 .
3. Enter the document number and the document item you want to look at and choose Execute .
Only if the information structure for this document contains several entries can you use reports RWMBON08 , RWMBON38 and RWMBON12 to updated
subsequent business volume data.
For further information on the document index, see Document Index for Retrospective Business Volume Update .
Features
There are two ways of carrying out the subsequent update of business volumes, and three reports can be used:
Subsequent business volume update using reports RWMBON08 and RWMBON38 (compile business volume data).
You use these reports to process intervals of rebate arrangements. You must process vendor and customer rebate arrangements separately using two
different reports.
Subsequent business volume update using report RWMBON12 (process worklist)
You can use this report to process any number of vendor and customer rebate arrangements simultaneously. You can carry out sequential processing or, to
speed up the process, parallel processing. However, if you carry out parallel processing, you need the relevant hardware resources (application servers,
processors, and so on).
With all three reports, the system updates the information structures of Subsequent Settlement, that is, all information structures for which active update rules
exist for the update group 000029 . In the standard system, this relates to the following information structures:
S074
Operative view (business volumes and income used for settlement accounting purposes)
S015
Information structure for evaluation (standard analyses, planning, and so on)
For information on how the individual reports work, see Compiling Business Volume Data (Report) and Processing a Worklist (Report) .
Constraints
Because this function does not redetermine prices, does not carry out a new valuation, and does not make any changes to the document items, the following
functional constraints exist:
Condition exclusions may not be processed correctly. You should therefore not work with condition exclusions if you are using this function.
The valuation of the document remains unchanged. In particular, the system does not post any provisions for accrued income.
The following examples illustrate the problems likely to occur:
Example
A rebate at corporate group level has been entered for condition type A001 (rebate arrangement 1), which is designed to take precedence over a condition
requiring subsequent settlement belonging to condition type A002 (rebate arrangement 2) of the procuring regional purchasing organization. Since no
adjustment of the document conditions takes place (in particular, no price determination) the exclusion cannot be taken into account.
The condition record A002 (rebate arrangement 2, regional incentive rebate) is included in the document conditions. A condition record belonging to
condition type A001 (rebate arrangement 1, incentive rebate at corporate group level) is now subsequently determined. The business volume update for the
condition record belonging to condition type A002 ought to be canceled due to the condition exclusion. It may also be necessary to reverse any posting to
provisions for accrued income, re-valuate the purchasing document, and post appropriate follow-on documents. However, none of this occurs. The update
remains effective despite the infringement of the condition exclusion.
The immediate vendor discount RL01 should only be valid if no subsequent rebate is granted. If such a rebate is determined retrospectively, the vendor
discount ought to be canceled (new valuation, follow-on documents). The ensuing changes in the subtotals could have far-reaching effects. The vendor
discount therefore remains unchanged.
1.5.5.1 Updating of Business Volume Retrospectively
Procedure
1. For vendor rebate arrangements, start program RWMBON08 ; for customer rebate arrangements, start program RWMBON38 .
Caution
If you want to update business volumes retrospectively, you must update all information structures. Under no circumstances enter a restriction.
1. If you initially want to carry out a check run to view any error messages that may be generated and correct any errors, select the Check run indicator.
In this case, the business volumes are not updated.
Caution
If you do not select the indicator, the system writes the update data created to the information structures. At the same time, the system records the
successfully processed document items in an index log.
You cannot carry out a business volume update for these document items again unless you carry out a complete recompilation of business volumes for
the arrangement (see Recompilation of Business Volumes and Incomes ).
1. Enter a version.
2. For test purposes, you can first enter a version that starts with the two characters &( . You can enter any character as the third character. You enter
version 000 as the operative version.
The user parameter MCR allows you to directly access the data of this version in all list functions for business volumes (business volumes, statement
of statistical data, standard analysis). To achieve this, enter the value 000 for the parameter MCR under System User profile Own data .
You can also write the program directly to version 000 . If errors occurred during processing of arrangements, these document items can be
reprocessed in another program run once the errors have been corrected. Multiple updates are not possible in the case of business volumes updated
retrospectively.
3. Narrow down the selection of rebate arrangements to be processed if necessary.
4. If documents are found to be missing, they are usually purchase orders, goods receipts, invoices, vendor billing documents, or settlement requests for
which price determination was carried out before the rebate arrangement was created. In exceptional cases, the updating of business volume may not be
carried out as intended. In this case, you can deselect the indicator Only retrospectively entered rebate arrangements . The system then processes all
the selected arrangements.
A rebate arrangement is regarded as having been created retrospectively if its creation date is later than or the same as the valid-from date.
5. If you enter a termination date and time, the system stops the program at the time specified.
If this happens, the system logs the already processed rebate arrangements under the run name, so that you can continue the processing with the next rebate
arrangement.
To continue an interrupted run, delete the New run indicator and enter the name of the interrupted run. Refer to the value help for the Run name field for
information on any interrupted runs.
Note
If a run is terminated prematurely, only the rebate arrangement numbers are recorded. So that you can continue the run with the same selection
parameters (condition granter, for example), you should save the selection parameters in a variant.
1. Execute the program. If there are a large number of rebate arrangements and related documents, schedule a background job. In the latter case,
deactivate the list output.
Results
Once the program has run in full, you can obtain a log that contains the updated business volumes, and any messages that occurred, for each rebate
arrangement. You can specify that the log should only contain the messages that occurred, and also define which messages are to be issued (only warnings,
for example).
The analysis function enables you to evaluate the results easily. This enables you to generate a list output of all document items plus any associated follow-
on documents, together with one or more notes on the course of the updating process. The list shows you which document items are contained in the
document index ( S111 ) and why updating was or was not carried out. You can also invoke the analysis function from within the list output of the Details
statement function.
You can choose whether to view all documents, and their condition records, that are relevant to the rebate arrangement or only those document items for
which updating has not yet been carried out. The latter are precisely those document items for which an error message has been issued or which, although
they are included in the document index, are not relevant to the concrete condition record (if a requirement is infringed, for example).
Note
If you wish to analyze the document items for which updating has just been successfully completed (no test run), choose All documents , since you have
just carried out the updating for these document items.
1.5.5.2 Document Index for Retrospective Business Volume

Update
Use
In order to carry out the retrospective update of business volumes, the system must be able to efficiently access all documents that may be relevant to a
retrospectively entered condition record. This is done using the "document index", which is an information structure within the Logistics Information System
(structure S111 ), and is also used by other applications in the SAP System.
The system supplies the information structure with the necessary data when a document item relevant to subsequent settlement is created, changed or
deleted. For each document item, the function creates an entry containing the document number, the item number and the price determination date, each time
the access sequence is accessed.
Prerequisites
So that the system can recognize document items that are relevant for subsequent settlement, you must set the following indicators for the vendor in the
purchasing view in the vendor master:
Subsequent Settlement indicator
The system uses this indicator to see which document items are relevant for subsequent settlement. Business volume data is only automatically updated for
these document items.
To reduce the volume of data, you set the Subsequent settlement index indicator for the vendor in the purchasing organization data.
Set this indicator for each supplier of the goods listed in the purchasing document, so that the system can create the relevant index entries. The actual
supplier of the goods can differ from the settlement partner. In view of the high volume of data, however, you should carefully consider whether you need to set
this indicator.
In the case of settlement requests, the system creates customer-side index entries if the relevant indicator is set for the vendor. In the case of documents
without a purchasing organization, the system always creates the index entries.
Caution
If you set the Subsequent settlement index indicator retrospectively, for example when putting the mechanism into operation for the first time, or if an
access sequence is added or changed, the corresponding index entries may be missing in documents that already exist. In this case, you must recompile
the document index.
If you also set the Subsequent settlement indicator for the first time when you set the Subsequent settlement index indicator, it is possible that all
existing document items are flagged as not relevant to the subsequent settlement process. A requirement in the calculation schema prevents conditions
involving subsequent settlement from being inserted for certain document items (e.g. delivery without charge). Similarly, the system does not insert such
document items in the document index. Select the indicator and retrospectively compile the document index.
For further information, see Retrospective Compilation of the Document Index .
Any contract items that exist should be flagged as relevant for subsequent settlement. Otherwise, newly created PO items referencing an outline
agreement item will similarly not be relevant to the subsequent settlement process. You may have to subsequently maintain existing purchase order items
that reference the contract.
You should therefore pick out all affected documents (purchase orders, delivery schedules, and outline purchase agreements) relating to the goods supplier
and set the Settlement indicator in the "additional data" of the relevant document items ( Overview Goto Further data Additional data ).
1.5.5.2.1 Subsequent Compilation of the Document Index
Procedure
To recompile the document index, proceed as follows:
1. Start one of the following programs:
RMCENEUA or RMEBEIN3 (for purchase orders and scheduling agreements)
RMEBEIL3 (for vendor billing documents)
RMEBEIZ3 (for settlement requests)
Note
Only use program RMCENEUA if you want to recompile other information structures in addition to information structure S111 . The other programs for
recompiling individual information structures are much more efficient.
1. Enter a version.
You can have the system write data to version 000 directly. You do not need to save the data first or compile it in a test version.
1. If you enter a termination date and time, the system stops the program at the time specified.
In the event of premature termination, the system logs the already processed documents under the run name so that you can resume the processing with the
next document.
To continue an interrupted run, delete the New run indicator and enter the name of the interrupted run. Refer to the value help for the Name of run field for
information on any interrupted runs.
Note
If a run is terminated prematurely, the system only records the document numbers. So that you can continue the run with the same selection parameters
(document date, for example), you should save the selection parameters in a variant.
1. Execute the program. If there are a large number of documents, schedule a background job.
Results
The document index is recompiled in full. For information on how to check this, please see the section Prerequisites in Subsequent Updating of Business
Volume Data .
1.5.5.3 Recompilation of Business Volume Data and Incomes
Purpose
You need to recompile business volume data and incomes if business volume data contains errors. If you perform this function, the incomes in the information
structures of Subsequent Settlement are recompiled, that is to say, all information structures for which active update rules exist for update group 000029 . In
the standard system, this relates to the following information structures:
S074
Operative view (business volumes and income used for settlement accounting purposes)
S015
Information structure for evaluation (standard analyses, planning, and so on)
Prerequisites
It is essential that you read the general notes on recompiling statistics. In particular, save the date, or save the business volume data in a second version. For
the recompilation, use a version intended for this purpose starting with the two characters &( .
Process Flow
You can recompile business volume data and incomes as follows:
Recompilation of Information Structures using Reports RWMBON08/RWMBON38 and RWMBON07/RWMBON37
You use these reports to process intervals of rebate arrangements. The recompilation of business volume data and incomes must be carried out separately for
vendor arrangements and customer arrangements.
1. You first recompile the business volume data using the following reports:
Report RWMBON08 for vendor arrangements
Report RWMBON38 for customer arrangements
In the reports, select the Recompilation indicator and see the following documentation: Compiling Business Volume Data
Note
These reports are also used for the subsequent updating of business volume data. For further information, see Subsequent Updating of Business Volume
Data .
1. You then recompile the rebate income data

You recompile the incomes using the following reports:
Report RWMBON07 for vendor arrangements
Report RWMBON37 for customer arrangements
You omit this step if settlement accounting has not yet taken place.
For further information, see Compiling Rebate Income Data (Report) .
Recompilation of Information Structures using Report RWMBON12
You use this report to recompile business volumes and incomes for any number of customer arrangements and vendor arrangements in one program run.
1. You first use the Create worklist function to create worklists for the arrangements in question.
2. For further information, see Creating a Worklist .
3. You then use report RWMBON12 (process worklist) put the arrangements in the worklists and process these in a single program run.
For further information, see Processing a Worklist (Report) .
1.5.5.3.1 Compiling Business Volume Data (Report)
Use
If you use reports RWMBON08 and RWMBON38 you can compile business volume data in the following ways:
Subsequent updating of business volumes
For further information, see Subsequent Updating of Business Volume Data .
Recompilation of business volume data with subsequent business volume update
Recompilation of business volume data without subsequent business volume update
For further information, see Recompilation of Business Volume Data and Rebate Incomes .
Caution
Ensure that no new documents are created while the program is running. In particular, background invoice verification must be deactivated.
Features
Before a complete recompilation of business volume data, you must ensure that any existing business volume data in the system is deleted, to avoid
business volumes being updated twice. Select the relevant indicator for this.
The business volume data for all information structures in the system is deleted providing they contain the characteristic Rebate arrangement or Condition
record number . The information structure should have a secondary index referring to the relevant characteristic.
If, during a recompilation , a large amount of data is to be added (at least 10% to 15% of the total data volume of the information structure concerned),
you can improve performance by deleting the secondary indexes and recreating them after the recompilation. Select the relevant indicator for this.
You can initially carry out a test run in order to view any error messages that may be generated and correct any errors.
You can specify that the execution of the program is terminated or interrupted by a certain point in time.
You can have the system issue a log. You can define what information the log is to contain:
Updated business volume data, including messages that occurred
Message log only
Here, you can also specify the type of messages that are issued (for example, warnings only).
During the program run, you can have the system create analysis data for the arrangements last processed.
This enables you to generate a list output of all document items plus any associated follow-on documents, together with notes on the course of the updating
process. This shows you which document items are contained in the document index and why updating was or was not carried out, for example.
Activities
The following procedure describes how you use the report, taking the example of the subsequent updating of business volume data:
Carrying Out Subsequent Business Volume Update
1.5.5.3.2 Compiling Rebate Income Data (Report)
Use
You can use reports RWMBON07 and RWMBON37 to recompile the information structures for income data for vendor and customer arrangements.
Prerequisites
Before you recompile incomes, you must carry out a recompilation of business volume data.
For further information, see Recompilation of Business Volume Data and Rebate Incomes .
Features
Before you recompile income data, you must delete any incomes that already exist in the system. By doing this, you ensure that incomes are not
updated twice. Select the relevant indicator for this.
When you do this, the relevant key figures for all information structures in the system are set to zero. However, this is only done if the information structures
contain the characteristic Rebate arrangement or Condition record number . The information structure should have a secondary index referring to the
relevant characteristic.
If a large number of data records are to be added (at least 10% - 15% of the total data volume of the information structure), you can have improved
system performance by deleting the secondary indices and then recreating them after the data has been restructured. Select the relevant indicator for
this.
You can initially carry out a check run in order to view any error messages that may be generated and correct any errors.
You can specify that the execution of the program is terminated or interrupted by a certain point in time.
You can have the system issue a log, if required.
This log contains the settlement document items, including provisions for accrued income and settled income, and any messages that occurred.
Activities
You enter the relevant information and a version.
For test purposes, you can first enter a version that starts with the two characters &( . You can enter any character as the third character. You enter version
000 as the operative version.
The user parameter MCR allows you to directly access the data of this version in all list functions for business volumes (business volumes, statement of
statistical data, standard analysis). To achieve this, enter the value 000 for the parameter MCR under System User profile Own data .
You can also write the program directly to version 000 . If errors occurred during processing of document items, these document items can be reprocessed in
another program run once the errors have been corrected.
1.5.5.3.3 Creating a Worklist
Use
You use this function to create worklists which you put certain objects in so that they can be processed at a later date.
In the worklist, you can mark any number of arrangements for which a recompilation of business volumes and/or income data or a subsequent update is to be
carried out, for example.
Procedure
To create a worklist for rebate arrangements, proceed as follows:
1. Choose object type Arrangement .
2. Enter an Object usage .
The object usage indicates the way in which the objects (arrangements) in the worklist are to be processed further. For the further processing of arrangements
(Subsequent Settlement), you can select one of the following object usages:
Subsequent updating of business volume data
Recompilation of business volumes and incomes
Recompilation of incomes
Recompilation of business volumes and incomes, including subsequent business volume update
1. For the object usage you entered, create a worklist by entering an ID and description for the worklist.
Results
You have created a worklist. You can use the 'Process worklist' function (report RWMBON12 ) to assign the arrangements that you want to process to this
worklist and carry out the actual processing ( object usage ) (see Processing a Worklist (Report) ).
1.5.5.3.4 Processing a Worklist (Report)

Use
You can use this report to put any number of objects in a worklist and then process them. In Subsequent Settlement, you can carry out the following kinds of
further processing for arrangements:
For further information, see Subsequent Updating of Business Volume Data and Recompilation of Business Volume Data and Incomes .
Use
You can use this report to put any number of objects in a worklist and then process them. In Subsequent Settlement, you can carry out the following kinds of
further processing for arrangements:
For further information, see Subsequent Updating of Business Volume Data and Recompilation of Business Volume Data and Incomes .
Prerequisites
Prerequisites
For objects (such as arrangements) that you want to process further, you must first create worklists for which a specific type of further processing is defined.
For further information, see Creating a Worklist .
Features
You have the following options for the worklists that you want to process:
Create worklist
From here, you go to the Create worklist function.
Change worklist
You can display and change the objects already in the worklist or add new objects.
Display worklist
You can display, but not change, the objects in the worklist.
You can initially carry out a check run in order to view any error messages that may be generated and correct any errors.
You can specify that the execution of the program is terminated or interrupted at a certain point in time.
You can carry out sequential processing or, to speed up the process, parallel processing. However, if you carry out parallel processing, you need the
relevant hardware resources (application servers, processors, and so on).
If, during a recompilation, a large amount of data is to be added (at least 10% to 15% of the total data volume of the information structure concerned),
you can improve performance by deleting the secondary indexes and recreating them after the recompilation. Select the relevant indicator for this.
You can have the system issue a message log. Here, you can specify the type of messages that are issued (for example, warnings only).
Activities
You enter the relevant information and a version.
For test purposes, you can first enter a version that starts with the two characters &( and has a third, freely definable, character. You enter version 000 as
the operative version.
The user parameter MCR allows you to directly access the data of this version in all list functions for business volumes (business volumes, statement of
statistical data, standard analysis). To achieve this, enter the value 000 for the parameter MCR under System → User profile → Own data .
You can also write the program directly to version 000 . During processing, if errors occurred for document items, these document items can be reprocessed
in another program run once the errors have been corrected.
Caution
Multiple updates are not possible in the case of retrospective updating of vendor business volumes.
1.5.6 Business Volume Comparison in Subsequent Settlement
Use
Data on the volume of business done with a business partner (expressed as value, quantities, points etc.) is continually updated internally for rebate
settlement purposes. At the same time, business partners determine and document the volumes of business done with you.
The business volume figures arrived at by the two parties for a rebate arrangement may differ, due to the vendor and customer assigning items to different
accounting periods for example. The business volume comparison serves as the basis for the reconciliation of your and your business partner’s figures, the
aim being to avoid having to make subsequent adjustments.
Prerequisites
For the business volume comparison, the following settings are necessary in Customizing for Subsequent Settlement :
Arrangement type
The business volume comparison is controlled by the business volume comparison type (see below), which is assigned to the arrangement type.
Business volume comparison type
The business volume comparison type determines the way in which the business volume comparison is to be carried out. Among other things, you can define:
whether a business volume comparison is allowed or mandatory for the period-specific conditions and/or the main condition of a rebate arrangement.
the way in which business volume that arises after a business volume comparison is to be taken into account in settlement accounting (for example
Add business volume data to comparison ).
the tolerance limits within which the business volume is to be compared. To do this, you can assign a business volume tolerance group (see below) to
the business volume comparison type.
Business volume tolerance group
In the business volume tolerance group, you can define the limits within which the business volume is to be compared for the period-specific conditions, the
main condition, and final settlement of a rebate arrangement.
You can assign business volume tolerance groups to User groups. By doing this, you can define the limits within which a specific user or groups of users can
carry out a business volume comparison. In this case, the user settings override the settings for the business volume tolerance group that you entered in
Customizing for the business volume comparison type.
Aggregation level and sort sequence for the business volume comparison
The aggregation level defines the level at which the business volume data is entered.
When you compare business volumes, you must bear in mind that your business partner’s fiscal year can differ from your fiscal year. You must therefore
ensure that the value entered for comparison purposes relates to the same period as the value stored in the system.
Features
Comparison of period-specific and main conditions
If comparison of business volumes has been agreed with a business partner as a precondition for partial or final settlement, the system will not allow
settlement accounting to take place until this comparison has been carried out.
Entry of an agreed value
If the business volume recorded by you differs from that recorded by your business partner, you can enter an agreed value. Internally, the system stores both
the value it actually determines and the agreed value, so that all changes can be traced and verified. The agreed value is used as the basis for settlements
effected thereafter.
The storage of both values also ensures that any additional business volume recorded after the comparison and agreement process can be identified and
additionally taken into account, provided that final settlement has not yet taken place.
Business volume comparison at various aggregation levels
The business volume comparison can be entered at any level of the key fields site, tax code, vendor, and month (analysis period). In the statistics, the data
entered is then broken down to the most detailed level on the basis of the updated business volume data.
Defining tolerance limits for the business volume comparison
You can define tolerance limits (business volume tolerance group) within which the business volume for a rebate arrangement can be compared. These
tolerance limits can also be defined per user. If the tolerance limits are exceeded or not reached in the business volume comparison, the system issues either
a warning or an error message, depending on your Customizing settings.
Adding new data records in the statistics of the Logistics Information System
You can still enter business volume data for sites (for example) even if no records for these sites exist in the statistics, that is to say, no business volume
data exists in the SAP system. This may be the case, for example, if the stores in question use a non-SAP system.
1.5.6.1 Carrying Out Business Volume Comparison and
Agreement
Procedure
1. On the Perform Comparison of Business Volume screen, enter the number of the desired rebate arrangement and press ENTER .
2. From the input help, select the settlement date of the period-specific or main condition for which you want to perform settlement accounting.
3. Confirm your entries.
You go to the overview screen for the business volume comparison, which displays an overview tree and a table for entering the business volume comparison.
The period-specific conditions for the arrangement are displayed in the overview tree. The condition that you selected on the selection screen is displayed in
black. Period-specific conditions that fall before the validity period of the selected condition are displayed in gray. In addition, the conditions for which business
volume has already been compared are marked with a green dot, and the conditions for which business volume has not yet been compared are marked with a
red dot.
The business volume date relating to the selected condition is displayed in the table.
Note
You can switch between the period-specific and main condition. To do this, choose either Period-specific condition or Main condition .
If the condition contains scales, you can display these scales for information purposes. Choose Goto Condition record.
Choose Income per scale to obtain an overview showing you the position of the scale level currently achieved within the scale as a whole and the
additional volume of purchases necessary to reach the next scale level.
1. Select the aggregation level at which you want to compare business volume data.
2. The business volume data can be displayed at any level of the key fields site, tax code, vendor, and month . You can select a valid aggregation level
from the input help (F4) for the Aggregation level field.
In the statistics, the data entered is then broken down to the most detailed level on the basis of the updated business volume data.
3. If the business volumes differ, enter a value that you agreed with your business partner.
4. The condition for which the comparison is carried out (not yet saved) is marked with a yellow dot in the overview tree.
5. Save your entries.
If you are not carrying out the business volume comparison for the first time, you can obtain information on the results of the last comparison, and on the
business volume at the time when last comparison was carried out. If this differs from the current level of business volume, an incoming invoice or goods
receipt must have been posted in the meantime.
If you wish to change data that has already been compared, the system will suggest the data of the last business volume comparison. However, you can also
display the current statistical data as a starting point for the business volume comparison. You can use the Adopt business volume function to copy the data
displayed in the entry table (for the current business volume, for example) to the current comparison.
Caution
If the business volume data according to your business volume statistics agrees with the corresponding data recorded by the vendor, consider whether you
really wish to save the result of the business volume comparison or whether it is preferable to reset the indicator "Business volume comparison" in the
rebate arrangement, in view of the absence of any discrepancies. Due to the increased volume of data, the system needs more time and storage capacity
during the settlement run if the results of a business volume comparison have been saved.
You will find details on the volume of business done with the vendor under Settlement accounting Display statement or Detailed statement and
in the Standard analysis for Subsequent Settlement.

HELP SAP. Purchasing

Uploaded by

Document Information

Original Title

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

HELP SAP. Purchasing

Uploaded by

Copyright:

Available Formats

Purchasing

PDF download from SAP Help Portal:

Created on April 12, 2016

1.1 Requirements Planning

1.1.1 Basic Principles

1.1.1.1 Requirements Planning: Supply Source Determination

1.1.1.2 Requirements Planning: Forecast

1.1.1.3 Requirements Planning: Forecast With Alternative

1.1.1.3.1 Alternative Historical Data

1.1.1.3.2 Post Distribution Forecasting

1.1.1.4 Requirements Planning: Using Delivery Relationships

1.1.1.5 Requirements Planning: Quantity Allocation (Push)

1.1.1.6 Requirements Planning: Determination of Requirements

For further information, see Collective Purchase Order .

For further information, see MM - Materials Management , MM - Consumption-Based Planning .

1.1.2 Planning Workbench

1.1.2.1 Working with Worklists

Additional Data Prerequisites What Happens If You Select Symbol

Application Toolbar for the Worklist Area

1.1.2.2 Online Planning

1.1.2.2.1 Reference Scenario

1.1.2.2.3 Using Online Planning

1.1.2.2.4 Using User Exits to Adapt Online Planning

1.1.2.3 Order Cancelation

1.1.2.4 Internet Services

1.1.2.5 General Settings

1.1.3.1 Replenishment: Inventory Management Types

Characteristics MM-based Inventory Management Replenishment-based Inventory Management

Number of stock types managed high only one

Materials movements documents created not available

Replenishment-based Inventory Management indicator not set set

1.1.3.2 Replenishment: Examples for using Replenishment

Replenishment for Franchisees and in Vendor Managed Inventory (VMI)

1.1.3.3 Replenishment: Master Data

1.1.3.3.1 Replenishment: Article Master Data for Sites

1.1.3.3.2 Replenishment: Article Master Data for External

1.1.3.3.3 Replenishment: Structured Articles

1.1.3.3.4 Replenishment: Logistical Variants

1.1.3.3.5 Replenishment: Requirement Groups

1.1.3.3.6 Replenishment: Example of Requirement Groups Usage

Requirement Group Assignment in the Site Master

Sites Merchandise category Description Requirement group

R151 R1115 Confectionery 01 (large)

R152 R1115 Confectionery 01 (large)

R153 R1115 Confectionery 02 (medium)

Replenishment Article Data at Requirement Group Level

Requirement group Reorder point Target stock

Replenishment Article Data at Site Level

Article Description Sites Reorder point Target stock

R100002 Chocolate R151 90 300

R100002 Chocolate R152 90 300

R100002 Chocolate R153 30 120

Replenishment Data at Site Level with Exceptions

Article Description Site Reorder point Target stock

R100002 Chocolate R152 80 300

01 (large) 100 300

Article Description Site Reorder point Target stock

R100002 Chocolate R151 100 300

R100002 Chocolate R152 80 300

R100002 Chocolate R153 30 120

1.1.3.3.7 Replenishment: Site Master Data

1.1.3.3.8 Replenishment: Check Consistency of Replenishment

1.1.3.4 Replenishment: Forecasts