Multilevel Replenishment:
Best Practices for Runtime Optimization
in SAP Forecas ting and Replenishment
Copyright
© Copyright 2008 SAP AG. 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 AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG 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.
Icons in Body Text
Icon Meaning Caution Example Note Recommendation SyntaxAdditional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help General Information Classes and Information Classes for Business Information Warehouse on the first page of any
version of SAP Library.
Typographic Conventions
Type Style Description
Example text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options.
Cross-references to other documentation.
Example text Emphasized words or phrases in body text, graphic titles, and table titles.
EXAMPLE TEXT Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE.
Example text Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.
Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.
Index
Copyright... 2
Icons in Body Text ... 3
Typographic Conventions ... 3
Introduction... 6
Purpose of the document... 6
System integration schema for this document ... 6
1. Optimize SAP Retail ... 7
1.1. Select the F&R-relevant article-site combinations in a meaningful way... 7
1.2. Consider the impact on runtime when changing Customizing objects... 8
1.3. Only activate the interfaces and change pointers that you really need ... 9
1.4. Do not perform unnecessary initial loads (use delta load if change pointers exist)…... 10
1.5. Perform delta loads several times a day... 11
1.6. Reorganize control tables regularly (transactions FRE30, FRE34) ... 11
1.7. Use net purchase prices from info records, if applicable... 12
1.8. Use immediate synchronization of reference numbers only if needed... 13
1.9. Send stock and consumption separately ... 13
1.10. Use caution with ‘High Level Filter for Sites’; if you use it, make sure you use it consistently ... 14
2. Optimize BIF Interface Processing in SAP F&R ... 14
2.1. Make sure the data of the current delta run is completely sent before you start to process the data in SAP F&R ... 14
2.2. Avoid processing of huge data volumes (such as consumption data) by using data selection ... 15
2.3. Switch Off the ‘Source of Supply Check’ in Order Inbound, if possible... 15
2.4. Configure the database so that it can properly handle the “load characteristic” of the Business Interface (BIF) tables ... 16
3. Optimize data and settings in SAP F&R... 16
3.1. Maintain Demand Influencing Factors (DIFs) in a meaningful manner ... 16
3.2. Work with exceptions, reorganize them, and consider switching off unnecessary exceptions ... 18
3.3. Activate only the analytical reports that you need... 18
3.4. Define forecast horizons only as long as needed ... 19
3.5. Use Compressed Data Management (CDM) instead of Time Series Data Management (TSDM) ... 19
3.6. Activate the ‘New Transportation Lanes’ Model in SAP F&R 5.0 ... 20
3.7. Activate New Location Product Interface Logic... 20
4.1. Run FRP every day (otherwise you risk initialization of data before the next FRP
run) ... 20
4.2. Make sure that the stock update is in time (before stock synchronization with FRP) to prevent a stock projection ... 21
4.3. Set up and balance the calculation of Forecast, Order Forecast, Parameter Optimization, FRP Cleanup with their frequency definitions in a meaningful way22 4.4. Schedule the FRP Parameter Optimization outside the critical time window ... 22
4.5. Divide the FRP run into steps, if applicable ... 23
4.6. Use the hybrid solution, if applicable ... 24
4.7. Activate ‘Deferred Checks’ for products without planning day, if applicable ... 25
5. Optimize SAP F&R outbound and SAP Retail inbound processing... 26
5.1. Start the outbound processing of order proposals during the FRP run only if there are free resources in the system ... 26
Introduction
Purpose of the document
The document comprises a collection of typical functional, organizational and configuration aspects to be considered regarding performance, runtime and data volume in an SAP Forecasting and Replenishment (SAP F&R) scenario integrated with SAP Retail. It will help you to configure and use the system to achieve the best results while reducing processing time.
Most of the aspects refer to SAP F&R 5.1 and SAP Retail ERP 6.0, EhP02. However, some of the points are general statements which also apply for earlier releases; others are changes that are also available for SAP F&R 5.0 and SAP Retail 4.6C PI 2004.1 SP10 or SAP Retail ERP2005 (ERP 6.0 EhP0). The document does not consider general technical performance relevant settings such as parallelization.
Detailed knowledge of both solutions is required.
Note that the points below are not fixed SAP recommendations, but rather possible discussion points. There is no guarantee that the list is complete.
For more information, see:
SAP Library
help.sap.com
under SAP Solutions SAP for Industries SAP for Retail SAP Forecasting and ReplenishmentThe Business Scenario Configuration Guide and the Scenario Security Guide for
Multilevel Replenishment are available on the SAP Service Marketplace:
service.sap.com/ibc
under Industry Solutions SAP for Retail Multilevel ReplenishmentSAP for Retail Master Guide in the SAP Service Marketplace under
service.sap.com/instguides
Scenario & Process Component List in the SAP Service Marketplace under
service.sap.com/scl
Workshops: W26FRF: SAP Forecasting and Replenishment: Functions (3 days) and
W26FRT: SAP Forecasting and Replenishment: Technical details (2 days). See
service.sap.com/retail
for training courses in St. Ingbertservice.sap.com/education
for training courses worldwide.System integration schema for this document
The following schema shows an example of how the data flows between the SAP Retail system, the SAP F&R system and the Forecasting and Replenishment Processor (FRP), which is an integral part of SAP F&R. The numbers indicate the places where you can optimize runtimes, performance or data volume:
1. Settings in SAP Retail that influence the data transfer to SAP F&R 2. Processing of interface records in SAP F&R
3. Settings within SAP F&R 4. Execution of FRP run
1. Optimize SAP Retail
1.1. Select the F&R-relevant article-site combinations in a
meaningful way
Impact on: Data volume to be processed in the interfaces; runtimes of data transfer reports;
data volume in SAP F&R
Applicability: General, but data reductions type is only available as of SAP Retail ERP 6.0
EhP02
Background: The replenishment type of the logistics data of the article is the marker for the
data transfer of all related data to SAP F&R. As soon as a replenishment type is assigned to an F&R replenishment type in Customizing for SAP Retail, the relevant article and all related data (depending on the data reduction type and further settings, such as location master data and all supply net information) is ready for transfer to SAP F&R with either the initial or the delta load.
There are special situations, especially in distribution centers, where you only need a reduced data set.
If you want to have the listing checked in the DC at which you order a product for a store, you only need a subset of the information that would be required if the product were replenishment-relevant for that DC. This means that you can save transportation lanes, time series data, and order proposals.
© SAP 2008 / Page 1
System Integration and Data Flow (Example)
SAP F&R 5.1
Inventory Order documents Time series Master dataSAP Retail
(SAP ERP 6.0) Bus ine ss Int erface v ia In ter fa ce Ta ble s /FR E /B IF* F&R tables FRP* run FRP Output files ERP / F&R SynchronizationFRP* Files
(1 directory per location)
F&R / ERP Synchronization F&R / FRP Synchronization FRP / F&R Synchronization Inter-mediate files FRP Input files 1 1 2 2 3 3
* FRP = Forecasting and Replenishment Processor
4
4
5
If you order a product for a store at a DC that uses cross-docking, SAP F&R can consider the replenishment lead times for the DC-to-store as well as for the vendor-to-DC. Therefore, SAP F&R needs master data for the product in the DC (product, location, location product, transportation lanes) but no time series and no order proposals.
Recommendation: Do not transfer excess data to SAP F&R. Only assign F&R-relevant
replenishment types to those article-site combinations that are intended to be replenished with SAP F&R. Generally, it is better to create new replenishment types in SAP Retail and assign them to F&R-relevant article-site combinations than make an existent replenishment type F&R-relevant.
For special situations (such as listing check, DC cross-docking process), you can use replenishment type 02 with the relevant data reduction type: 01 for listing check and 02 for additional scheduling in DC cross-docking processes (note that the data subset of 02 includes 01).
Implementation:
Creation of Replenishment Types: IMG: Materials Management Consumption-Based Planning Master Data Check RP Types: You can create as many new
replenishment types with replenishment procedure ‘N’ as you need for mapping with the F&R replenishment types
Mapping of Retail and F&R replenishment types: IMG: Integration with Other
mySAP.com Components Forecasting and Replenishment Define F&R Replenishment Types
1.2. Consider the impact on runtime when changing
Customizing objects
Impact on: Runtime of delta transfer report (FRE_DELTA_LOAD)
Applicability: General, but some of the objects are only available as of SAP Retail ERP 6.0
EhP02
Background: Changes you make to Customizing objects for SAP Retail (such as factory
calendars, planning calendars, processing methods, rounding rules or replenishment types) will not be recognized by change pointer analysis. However, in order to make the change effective for data transfer to SAP F&R, you need to run special reports that create the required change pointers not only for the Customizing object itself but also for all master data objects that are affected by the changed Customizing object. Depending on the number of master data objects the Customizing object is assigned to, the number of change pointers and therefore data records to be transferred with the next delta load can be very large.
Recommendation: Estimate the number of records that will be affected by your intended
Customizing change and plan enough time for both reports, the change pointer generating reports (see below) and the data transfer report (for example, delta load). You can estimate the additional time that will be required by comparing the number of additional change pointers against the number of change pointers in a typical delta load.
Implementation:
To estimate the number of records, you can use transaction WRFMASSMAT
-Integrated Mass Change. Alternatively, you can select the values in the relevant
Find the transactions to be performed after Customizing changes in SAP Easy Access
Forecasting and Replenishment (transaction WFRE00): Data Transfer to SAP F&R after Customizing Change FRE20 to FRE25 (Prepare Transfer of …) and FRE27-Transfer of Structured Articles).
1.3. Only activate the interfaces and change pointers that you
really need
Impact on: Data volume of change pointer tables, processing logic and runtime of the data
transfer reports
Applicability: General, but some of the interfaces and change pointers are only available as
of SAP Retail ERP 6.0 EhP02
Background: You generally activate special interfaces (such as hierarchies, procurement
cycles, and so on) in SAP Retail Customizing. These settings allow you to filter data records to be transferred to SAP F&R.
For example, if you do not activate procurement cycles, SAP Retail will send transportation lane records without procurement cycles.
Moreover, you can activate change pointers for different message types separately; for example, FRE_ART_HIER or FRE_SUPPLY_NET. Whenever you make changes to objects with activated message types, change pointers will be created (usually in table BDCP2). However, if you do not send these objects to SAP F&R via a delta transmission, the change pointers will not be processed and will remain in the change pointer table.
Recommendation: Only activate the interfaces and the message types for objects that you
transfer from SAP Retail to SAP F&R. For example:
If you do not want to send article hierarchies from SAP Retail, you should not activate the message type (FRE_ART_HIER) for change pointer analysis.
If you do not want to send procurement cycles from SAP Retail, you should not activate the procurement cycle interface in the Basic Settings for Data Transfer. (However, you should activate the message type FRE_SUPPLY_NET for other changes in the transportation lanes).
The following table lists the change pointers and the related interfaces for SAP ERP 6.0 EhP02 and higher:
Message types of change pointers (see transaction BD52)
Use Optional Interfaces in Basic Settings for
Data Transfer or special transfer
transactions FRE_ART_HIER (Article
hierarchy) Optional Interface: Article hierarchy
FRE_ART_SITE (F&R-relevant
article site combinations) Mandatory
FRE_DIF_NO_SITES (Number
of supplied sites - DIF) Optional Transactions: FRE16 and FRE17 (Initial and
Delta Transfer of DIF Occurrences for No. of Supplied Plants)
FRE_LAYMOD (Layout
modules) Optional Interface: Layout Modules
FRE_LOC_ADDRESS (Site
address) Mandatory
FRE_LOC_SITE (Site) Mandatory
FRE_LOC_VENDOR (Vendors
of a site) Mandatory
FRE_PLIFZ (Planned delivery
time) Mandatory (Included in transportation lanes)
FRE_REF_SITE (Reference
site) Optional Interface: Site Grouping Data
FRE_REL_PRO (Release
Profile) Optional Interface: Release Profile
FRE_SUBST_ASSIGNMENT
(Substitution assignment) Optional Interfaces: Substitution Assignments and Switchover information
FRE_SUBST_ASSORTMENT (Changes of assortment assignments)
Optional Interfaces: Substitution Assignments and Switchover information
FRE_SUPPLY_NET (Supply net information)
Mandatory
Implementation:
Activation of Change Pointers for Message Types: Transaction SALE: Modeling and
Implementing Business Processes Master Data Distribution Replication of Modified Data Activate Change Pointers for Message Types
Activation of interfaces: IMG: Integration with Other mySAP.com Components
Forecasting and Replenishment Maintain Basic Settings for Data Transfer: General Interface Activation
1.4. Do not perform unnecessary initial loads (use delta load
if change pointers exist)
Impact on: Data volume of change pointer tables, overall runtime of data transfer reports (in
case data is sent twice)
Applicability: General, but some of the interfaces and data transfer transactions are only
available as of SAP Retail ERP 6.0 EhP02
Background: After you activate the change pointer analysis in general and for the relevant FRE* message types, the system will create a change pointer for each F&R-relevant change
made in the application. However, the reports for initial data transfer (such as FRE01 - Initial
Transfer of Data, FRE11 - Initial Transfer of DIF Occurrences for Promotions and others) will
not process these change pointers and the change pointer records will accumulate in the change pointer table (or you might send the same data again if you scheduled the delta load
Recommendation: Use FRE01 – Initial Transfer of Data only for data records for which no
change pointers exist (that is, in the very beginning) or for the general transfer of merchandise category hierarchies, vendors, and so on.
Use FRE02 – Delta Transfer of Data and other delta transfer reports whenever change pointers exist.
For example, if you assign an F&R-relevant replenishment type to an article-site
combination, the system will create a change pointer; you then use the delta load to transfer this article-site combination and its related information.
You can also use report FRE_REINIT_LOAD to resend data. It has two advantages compared to an additional initial load:
It only sends the selected data, not the related data (for example, you can reinitialize product data without sending the related location data).
In case of transportation lanes, it sends deletion records first and new insert records afterwards (for example, if the validity period of a lane has changed, the
re-initialization load first deletes the lanes in question and then creates new ones in SAP F&R).
1.5. Perform delta loads several times a day
Impact on: Runtimes and workload balancing of delta transfer reports over day
(FRE_DELTA_LOAD)
Applicability: General, but some of the interfaces and data transfer transactions are only
available as of SAP Retail ERP 6.0 EhP02
Background: SAP Retail collects change pointers for certain data changes, such as master
data and purchase orders. If you make changes to Customizing objects, you have to run reports that create change pointers for all master data records that are affected by these Customizing changes (seeChange Customizing objects…). The relevant data records have to be sent to SAP F&R before the next FRP run at the latest. However, the workload for both systems might be high in the evening anyway (for example, because of consumption upload). As a consequence, you can balance the workload of the systems by sending information at frequently intervals.
Recommendation: Schedule the delta load (report FRE_DELTA_LOAD) several times during
the day. Schedule the final delta transfer of the day at a time when you do not expect any more change pointer related changes. Although the overall runtime of all delta loads may be higher, the runtime of the last delta load can be reduced considerably.
1.6. Reorganize control tables regularly (transactions FRE30,
FRE34)
Impact on: Data volume in control tables (housekeeping), runtime of data transfer reports Applicability: General, but some of the reorganization reports are only available as of SAP
Retail ERP 6.0 EhP02
Background: Control tables are designed to improve the runtime of data transfer reports
(such as tables FRE_OP_PO_KEY and FRE_MD_PRODUCT) considerably. However, they need to be reorganized regularly to check whether all entries are still relevant.
SAP Retail provides transactions for reorganizing control tables (see below).
Recommendation: Schedule the reorganization of control tables on a weekly basis. The
following transactions are of particular importance:
FRE30 - Delete Unnecessary Entries from Control Table for F&R Products checks the
table and, if possible, deletes records and sends the deletion records to SAP F&R.
FRE34 - Delete Completed Records from Control Table FRE_OP_PO_KEY deletes
completed purchase orders after a specified number of days and can also check whether the purchase order still exists (see the F1 help for Relevance Check). You should run FRE34 with relevance checking once a week per site; that is, daily, but only for a subset of sites.
Implementation: SAP Easy Access Forecasting and Replenishment (transaction WFRE00): Reorganisation of Control Table Entries used for Transfer to SAP F&R …
1.7. Use net purchase prices from info records, if applicable
Impact on: Runtime of data transfer reports (initial load, delta load); possibly also functional
impact on the accuracy of calculations that may use the purchase price in SAP F&R (see below)
Applicability: As of SAP Retail 4.6C PI 2004.1 SP10
Background: By default, when sending supply net information from SAP Retail to SAP F&R,
the Retail system carries out standard purchase price determination in order to determine the effective purchase price for each purchasing info record that has to be sent. Alternatively, the system can determine the net price from the purchase info record instead of the effective purchase price. This reduces the time needed for the purchase price determination and thus for the initial and delta load. (Alternatively, you could implement a BAdI for the purchase price determination.)
The purchase price in SAP F&R can be used in the following functions: Source of supply determination
Requirement quantity optimization (more specifically, vendor restrictions and economical order quantity optimization)
Order proposal release strategies
Display of purchase values in the Replenishment Workbench
Recommendation: First consider which purchase price (net or effective purchase price or
other) you need in SAP F&R for your business, taking into account the functions that are based on the purchase price (see above). You should also make sure to update the price in the purchase info record (transaction ME1B)outside the critical time frame before running delta load.
If SAP F&R processes do not require purchase prices, they should not be transferred to SAP F&R.
Implementation: SAP Retail: IMG: Integration with Other mySAP.com Components Forecasting and Replenishment Maintain Basic Settings for Data Transfer: Options for Purch.Price Determ:
Standard Price Determination Net Price from Purchase Info Record
No Price Determination
1.8. Use immediate synchronization of reference numbers
only if needed
Impact on: Data volume of delta load
Applicability: As of SAP Retail 4.6C PI 2004.1 SP10
Background: When an order proposal is transferred from SAP F&R to SAP Retail and posted
there, SAP Retail can send back the purchase order number to SAP F&R; this number will become the reference document number in the SAP F&R order proposal. This can be done without any changes occurring in SAP Retail; that is, the incoming purchase order will be put into a buffer to be sent back to SAP F&R (‘Document synchronization’). The actual data transfer can happen immediately (‘Transmission from inbound immediately’) or with the next delta load. However, this means that the entire purchase order will be sent back for the purpose of the purchase order number as reference. If you do not activate this function, the purchase order number will only be transferred to SAP F&R when the purchase order is changed in SAP Retail (such as after a goods receipt).
Recommendation: If you do not need the SAP Retail purchase order numbers as references
in the SAP F&R order proposals immediately, but only with the next delta load, you can switch off the immediate transfer. If you can wait until further processing has been done in SAP Retail, you can even switch off the document synchronization completely.
Implementation: SAP Retail: IMG: Integration with Other mySAP.com Components Forecasting and Replenishment Maintain Basic Settings for Data Transfer: ‘Document
synchronization active’ and ‘transmission from inbound immediately’. The ‘transmission from inbound immediately’ setting is applied to the document number synchronization as well as to changes of the purchase order resulting in change pointers and delta records.
1.9. Send stock and consumption separately
Impact on: Stock and consumption inbound into SAP F&R, earliest time frame possible to
start FRP run
Applicability: General
Background: Example ‘store scenario’: Depending on the store closure times, POS sales
data upload might occur late in the evening. However, the end-of-day stock (excluding POS sales) might be available earlier in SAP Retail (for example, if all goods movements are finished before the POS upload). There is no need to wait for the consumption upload to be posted in SAP Retail before sending stock in POS sales to SAP F&R because you can post POS data directly in SAP F&R, too, and then subtract it from the stock figures in SAP F&R.
Recommendation: If applicable, you can send the stock information from SAP Retail to SAP
F&R before posting the POS upload in SAP Retail; that is, the stock figures will represent stock without POS sales. You can then send the POS data from the POS Inbound Processing Engine (PIPE) of your SAP NetWeaver Business Intelligence (or from another system) in parallel to SAP Retail and to SAP F&R. The stock in SAP F&R will be updated with the POS sales.
Implementation: Schedule the stock upload from SAP Retail for a time when you do not
expect any more stock changes (except by POS upload). Send the POS data from PIPE (for example) directly to SAP F&R as soon as it is available. You have to configure the Time Series Interface in SAP F&R properly to make sure that the POS sales figures will be
subtracted from the stock values in SAP F&R: IMG: Forecasting and Replenishment
Interfaces Maintain Time Series Interface: Activate the LIME relevance indicator for the
qualifier 3000.
Note that the POS data can serve as a trigger for the time-critical FRP sequences (to be configured in the time series interface ‘FRP Trigger indicator’) and in the FRP start profile).
1.10. Use caution with ‘High Level Filter for Sites’; if you use
it, make sure you use it consistently
Impact on: Data consistency between SAP Retail and SAP F&R Applicability: General
Background: The ‘High Level Filter for Sites’ is a list of sites in Customizing for SAP Retail.
The list specifies the sites for which you want to allow data transfer to SAP F&R. You can use it in case you want to prepare the set-up of master data for SAP F&R but not send it yet to SAP F&R. If you activate the check in the initial or delta load, then the system will check this list before sending the data. However, this filter has two disadvantages:
It may require additional maintenance effort.
If you forget to activate the filter before running a data transfer report, you might send data to SAP F&R which is not intended for transfer.
Recommendation: Decide whether you really want to use the ‘High Level Filter for Sites.’ Be
aware that this filter needs to be maintained manually (and therefore can be a possible source of errors) and that its use in initial and delta load must always be done consistently (either always use it or never use it).
Realization: If you do not want to use the site filter, you do not have to do anything. If you
want to use it, make the following settings:
IMG: Integration with Other mySAP.com Components Forecasting and
Replenishment Define High Level Filter for Sites: list the F&R-relevant locations
Transaction FRE01 - Initial transmission of Data to F&R, FRE02 - Transfer Changed
Data to F&R and also the transmission transaction that includes the corresponding
‘Filter over customized sites?’: Always activate it.
2. Optimize BIF Interface Processing in SAP F&R
2.1. Make sure the data of the current delta run is completely
sent before you start to process the data in SAP F&R
Impact on: Data consistency between SAP Retail and SAP F&R
Applicability: General, however, interface logic partly changed as of SAP Retail ERP 6.0
EhP2 and SAP F&R 5.1
Background: Most of the SAP F&R interfaces work with a concept that requires merging of
interface table entries in case several different delta records for the same object are sent to the buffer tables during the day (exception: transportation lanes and location products, see SAP Notes 1102042 and 1169925). This can be critical when the entries in an interface table are supposed to be posted at the same time as new incoming data is received. Therefore,
Recommendation: Schedule enough time for sending the reports in SAP Retail before the
starting the processing reports in SAP F&R, so the data in the F&R interface tables is complete. To make sure that the first process is finished before the second starts, you can use special job scheduling software that can handle cross-system job scheduling.
You can also use transactions FRE_C1 and FRE_C2 in SAP Retail to check data consistency between the systems.
2.2. Avoid processing of huge data volumes (such as
consumption data) by using data selection
Impact on: Inbound interface processing Applicability: General
Background: If the volume of data in the interface table is too large, the work process can
run out of memory.
Recommendation: You can split the processing into several independent jobs for disjoint
data subsets.
Implementation: Transaction /FRE/BIF: Use the selection criteria to filter the data you want
to process.
Note that it depends on the interface objects, which selection criteria will apply. You can judge this from the names of the field groups.
For example: For inbound processing of order proposals, the system will only filter data according to the selected source location and will disregard possible product selections (since it makes no sense to post the order proposals only partially).
2.3. Switch Off the ‘Source of Supply Check’ in Order
Inbound, if possible
Impact on: Runtime of order inbound Applicability: As of SAP F&R 5.1
Background: By default, the system performs a master data consistency check during the
order inbound process. For every order proposal item in the order inbound interface, it checks that the locations, products and transportation lanes are valid in SAP F&R. If not, the system raises exceptions and leaves the orders as erroneous records in the interface tables. The check might be helpful during the implementation phase for detecting master data
inconsistencies. However, if you use transactions FRE_C1 and FRE_C2 to check the data consistency the ‘source of supply check’ might be dispensable. It should be definitely switched off when loading historical orders (because the system always checks the current master data).
Note that this check is called ‘Source of Supply Check’, although it is actually a master data check for information that is used in the source of supply determination.
Recommendation: When using SAP F&R in a productive system, you can usually switch off
the Source of Supply Check in the order inbound process.
Implementation: IMG: Forecasting and Replenishment Interfaces Source of Supply Determination in F&R Order Inbound: activate the flag ‘SSD check off”.
2.4. Configure the database so that it can properly handle the
“load characteristic” of the Business Interface (BIF)
tables
Impact on: Runtime of processing the business interface (BIF) tables Applicability: General
Background: The volumes of the BIF tables vary widely throughout the day: Directly after
processing the data, they are empty, or nearly empty. Analyzing the table statistics at that time does not provide representative data for database configuration activities. The impact of wrong statistics can be smaller or larger, depending on the operating system.
Recommendation: A possible solution is to collect the database statistics once the BIF
tables are filled and use these statistics for the BIF tables for a longer period of time.
3. Optimize data and settings in SAP F&R
3.1. Maintain Demand Influencing Factors (DIFs) in a
meaningful manner
3.1.1. Create only the DIFs you really need
Impact on: Runtime of FRP (Forecasting module)Applicability: General. However, as of SAP F&R 5.0, the problem can be avoided by
implementing SAP Note 1234578 (please check the release and support pack)
Background: You create Demand Influencing Factor Identifiers (DIF IDs) in F&R
Customizing. The DIF ID contains a DIF type and additional settings that specify the handling of the DIF occurrences that you will later create in the application. Each DIF ID in
Customizing, whether you use it in a DIF occurrence or not, takes up FRP runtime (except for DIF ID with Boolean DIF types defined on the location level).
Note that the logic will change when you implement SAP Note 1234578. The system will then consider only relevant DIF Identifiers in FRP, with the help of available DIF delta records. However, it will be important then that you regularly reorganize obsolete DIF delta records.
Recommendation: Only create DIF identifiers in Customizing if you really need them. As a
rule of thumb, you can have about 5-10 DIF IDs. Try to bundle DIF occurrences that have a similar impact on sales behavior into one DIF ID (for example, you do not need special DIF IDs for different promotions). When predicting the effect of a future DIF occurrence, the system only analyzes past DIF occurrences with the same DIF ID as the future DIF occurrences involved.
You should thoroughly investigate the influence of DIFs on the forecast and replenishment results using representative data.
Special recommendation for distribution centers (DCs): If you use one SAP F&R
installation for both stores and DCs, you might need different DIF occurrences for them; for example, different DIFs for store promotions and the corresponding DC promotions. However, this causes additional runtime in all locations unless you implement SAP Note 1234578. Therefore, you should use the same DIF ID for promotions in stores and in DCs as long as the attributes in the DIF ID Customizing are in agreement. There is no impact on the forecast, but data volume and FRP runtime are reduced considerably. Once you have implemented the SAP note 1234578, you can ignore this recommendation.
Implementation: SAP F&R: IMG: Forecasting and Replenishment Demand Influencing Factors Define Demand Influencing Factors: create only the ones you really need, create
only one or few DIF IDs for similar events (such as promotions).
3.1.2. Assignment on the location level and generic assignments
Impact on: Data volume, maintenance effort and runtime of FRPApplicability: General
Background: You define the assignment level (location or location product) in Customizing
for DIF Identifiers (DIF IDs). As a result, you assign locations or location products to the relevant DIF occurrences. In the case of assignment on the location level, the system checks the impact of past DIF occurrences for all products in that location and will show a DIF effect only for those products that were affected by the DIF occurrence. For assignments on the
location product level, the system only checks the impact of the DIF occurrences on the
assigned location products. Nevertheless, specifying DIF occurrences on the location product level leads to a considerable increase in FRP runtime (as well as data volume in FRP) compared to specifying them on location level.
Apart from the configuration of the DIF ID, you can use generic assignments in the DIF occurrence definition; that is, you can make assignments for all locations, all locations of a location type, and all products. This again reduces the data volume and access time in SAP F&R.
Recommendation: Whenever possible (for example, for all calendar events), you should
choose ‘location’ as the assignment level for DIF IDs. There is no functional disadvantage, and you can reduce data volume and runtime.
Use generic assignments in the DIF occurrence definitions, if applicable. If you use a generic product assignment, you should check whether it would also be possible to choose ‘location’ as the assignment level in the Customizing for the DIF IDs.
Implementation: IMG: Forecasting and Replenishment Demand Influencing Factors Define Demand Influencing Factors: ‘Assignment Level’ Location
3.1.3. Additional configuration settings for DIF Identifiers in
Customizing
Impact on: Runtime of FRP
Applicability: General, but Related Sales Dependency is only available as of SAP F&R 5.1 Background: There are additional settings in Customizing for DIF IDs that have an impact on
the FRP runtime (more specifically, on the forecast calculation):
Past Time Horizon for Changes: This setting is only necessary for the Sales Price DIF
type. For all other DIF types, there is a delta handling that guarantees that changes in the past and on DIF occurrences will be transferred to FRP.
Use as Consumption Reference: You can use this function if you have a consumption
reference assigned to the master data of a location product that also considers the DIF occurrences of the reference product.
Related Sales Relevant: This setting is a prerequisite for DIF IDs used in Related Sales
Dependencies
Past Time Horizon for Changes: Use this setting only for the Sales Price DIF type and
enter a time frame that is only as long as necessary.
Use as Consumption Reference: Use this function only if you frequently use
consumption references for location products with corresponding DIF IDs. Only then you can expect a significant improvement of the forecast quality, which is worth the additional runtime.
Related Sales Relevant: Only activate this setting and assign Related Sales
Dependencies if there is a business benefit.
Implementation: IMG: Forecasting and Replenishment Demand Influencing Factors Define Demand Influencing Factors
3.2. Work with exceptions, reorganize them, and consider
switching off unnecessary exceptions
Impact on: FRP Runtime, data volume, evaluation of exceptions in workbenches Applicability: General
Background: All program processes in SAP F&R can raise exceptions, which include not
only errors and warnings but also information messages. They can be technical or more business-related. As long as the situation does not change, the exception will be raised again and again.
Recommendation: To avoid the creation of exceptions that are caused by master data
inconsistencies, maintain your master data properly. Switch off exceptions that you do not want to consider in your daily work. An example might be a low level exception on the product level when a high level exception on the location level is also available. Change the default settings for the validity period in Customizing to as low a value as possible, still taking into consideration that exceptions are probably not processed over the weekend. Delete expired exceptions daily.
Implementation:
To customize exceptions (for example, switch them off): IMG: Forecasting and
Replenishment Exception Management Maintain Configuration Data for High Level Exceptions and Maintain Configuration Data for Low Level Exceptions
Deletion of exceptions after the expiration date and (optional) extraction to BI: run report /FRE/DB_MSG_REORGANIZATION. For parallel processing of this report refer to SAP note 1241003
3.3. Activate only the analytical reports that you need
Impact on: Runtime of FRP Sequence NON_EXC_ANA; data volume of analytical tables Applicability: General
Background: You can activate weekly and daily reports in SAP F&R Customizing for
reporting in SAP NetWeaver Business Intelligence (SAP NetWeaver BI). As a result, the system collects special information in analytical data base tables (/FRE/ANA*) before the SAP NetWeaver BI extracts them. Part of this information can result from the FRP run that
transfers the requested information in the FRP sequence NON_EXC_ANA to SAP F&R. Therefore, the analytical data for the Forecast Quality Report results in a higher work load,
forecast, as well as the forecasts calculated n and m weeks ago. This means that two additional forecast time series need to be stored (see Key Figure Parameters HFCSTPER1 and HFCSTPER2).
Recommendation: In F&R Customizing, switch off the analytical reports that you do not
need. For the forecast quality report, it may also be sufficient for your business to work without one or both n-/m- step ahead-forecasts in order to only compare the actual consumption with current forecast.
Implementation: IMG: Forecasting and Replenishment Analytics Configure Analytics:
Deactivate the reports that you do not need. Leave the ‘Extra Forecast Period 1’ and/or ‘Extra Forecast Period 2’ blank if you do not need the comparison of actual consumption with forecast calculated n or m weeks ago.
3.4. Define forecast horizons only as long as needed
Impact on: FRP runtime, volume of time series data
Applicability: General, but order forecast is only available as of SAP F&R 5.1 Background: The forecast horizon is defined as the number of weeks for which FRP
calculates a forecast. The horizon has impact on the runtime of the FRP run. You can store the forecast values in time series in two granularities: week and day. The time series data is needed for display purposes. You can define the number of future weeks for the storage independent of the forecast horizon itself.
For example, if the forecast horizon is defined as 6 weeks, you can store 6 weeks on a weekly level but only 3 weeks on a daily level.
Recommendation: Chose appropriate forecast horizons for the location products. Products
with short replenishment lead times usually need short forecast horizons (for example, 6 weeks). Define a reasonable number of weeks for storage of forecast time series, especially with daily granularity.
For example, for a seasonal product you might want to have a forecast of 52 weeks and also store 52 weeks on a weekly base for display purposes. However, you could restrict the storage of daily forecast values to 4 weeks.
Implementation: IMG: Forecasting and Replenishment F&R Processor Maintain Base Profile: here you can define the Operative Forecast Horizon, Output Weekly and Output Daily
values on the location level, because the Base Profile is assigned to the location master data. You can override the location settings by maintaining the relevant fields in the location product data with the Mass Maintenance for Location Products transaction.
3.5. Use Compressed Data Management (CDM) instead of
Time Series Data Management (TSDM)
Impact on: Data volume in SAP F&R, runtime for reading and writing time series, runtime of
inbound interface processing
Applicability: As of SAP F&R 5.0
Background: As of Release 5.1, the system automatically uses Compressed Data
Management (CDM) to store special time series data (see Key Figure Parameters (KPRM) of planning data, estimated forecast error and merged consumption). By default, all other time series are stored in Time Series Data Management (TSDM).
Recommendation: You can migrate all time series from TSDM to CDM. This is also possible
with SAP F&R 5.0 (see SAP Note 1127813).
Implementation: Refer to SAP Note 1224830.
3.6. Activate the ‘New Transportation Lanes’ Model in SAP
F&R 5.0
Impact on: Outbound interface processing of SAP Retail, SAP F&R inbound interface
processing logic of transportation lanes, interface logic, runtime of interface processing and data consistency in an SAP F&R 5.0 system
Applicability: As of SAP F&R 5.0 and SAP Retail ERP 2005 (ERP 6.0 EhP0)
Background: As of SAP F&R 5.1, transportation lanes for products are stored in a new F&R
table. Moreover, changes were made to the BIF interface processing logic; in particular, the X-field concept for updated fields was changed. For further details, see SAP Note 1102042.
Recommendation: You can also use the new transportation lanes in SAP F&R release 5.0. Implementation: Refer to SAP Note 1143303.
3.7. Activate New Location Product Interface Logic
Impact on: BIF inbound processing logic of location products Applicability: As of SAP F&R 5.1 and SAP Retail ERP 6.0 EhP2
Background: Similar to the new interface logic for transportation lanes for products in
connection with the New Transportation Lane Model, there is an option available for the location product interface. For further details, see SAP Note 1169925.
Recommendation: In order to improve the performance of the interface, you should switch to
the new interface logic. However, you should be aware that there are also changes necessary on the ERP side that are provided with SAP ERP 6.0 EhP2 SP03 or EhP3 SP02.
Implementation: Refer to SAP Note 1169925.
4. Optimize the FRP run
Note: The goal of the following points is not necessarily to shorten the overall FRP runtime
for a location, but rather to use the critical time window in a meaningful way. The critical time window is customer-specific, but usually starts with the availability of updated consumption data in F&R (which can be late, especially in store scenarios) and ends with the availability of order proposals and exceptions in F&R for the upcoming planning day. The steps to be performed within the critical time window are, by default, processed within sequence
AUTO_REPL_AND_OPRM. If the critical time window is short, it makes sense to optimize the
FRP run in such a way that the sequence AUTO_REPL_AND_OPRM can be finished on time even if the overall runtime is prolonged.
4.1. Run FRP every day (otherwise you risk initialization of
data before the next FRP run)
Applicability: General
Background: FRP checks the last FRP run execution and automatically retransfers all
consumption time series to FRP core modules if the last run was not performed the previous day. Additionally, FRP calculates a new forecast for all location products, regardless of their regular forecast schedule. As a result, the runtime for the FRP sequence
AUTO_REPL_AND_OPRM within the critical time window is increased considerably due to the prolonged consumption data synchronization from F&R to FRP and the additional forecast calculations. This fact should be also considered in testing environments where FRP does not run on a daily basis because it could distort the validity of runtime measurements.
Recommendation: Before collecting runtimes, you should make sure that FRP was
performed the previous day for the locations in question.
In operative systems, make sure you schedule FRP every day. If you do not want to perform forecast and requirement calculation on a certain days of the week (for example, Sunday) you can schedule the forecast calculation accordingly and can switch off the requirement
calculation in the FRP Process Control Profile for that day. The system will then perform a shortened FRP run with only consumption and stock updates. However, you might lose the following functionality for the day without requirements calculation: If the system performs the requirement calculation on a day that is not an order day for the location product in question, it will check the current stock and will raise an exception if there is a possibility that you might run out of stock.
Implementation: Use the dispatcher (/FRE/FRP_DISP_ACT - Activate and Start Dispatcher)
or schedule report /FRE/FRP_MID_BASIC on a daily basis. To schedule the Forecast and Requirement Calculation, configure the FRP Process Control Profiles assigned to the target locations. You can find more information underSet-up and balance the calculation of Forecast…
4.2. Make sure that the stock update is in time (before stock
synchronization with FRP) to prevent a stock projection
Impact on: FRP runtime (in particular requirement calculation) Applicability: General
Background: FRP checks the time stamp of the last stock update in SAP F&R. An FRP run
is always assigned to a certain planning date, even if the calendar date for processing is different. The date of the last stock update should correspond to the planning date. If not, FRP internally calculates the expected stock on the planning day using the last stock figure, the available consumption forecast, and all expected goods movements (stock projection). The stock projection is used to overcome problems with late stock updates and is therefore important from a functional point of view; however, the situation should be avoided to save runtime.
Recommendation: Make sure that the stock is usually transferred to SAP F&R in time to
avoid FRP performing the stock projection. Alternatively, make sure that the FRP sequence AUTO_REPL_AND_OPRM will be started after the stock update of a location has been completed.
Implementation: See below for more information about FRP scheduling. You could even use
the stock update as a trigger for sequence AUTO_REPL_AND_OPRM. This works similarly to the use of consumption data as anFRP trigger.
4.3. Set up and balance the calculation of Forecast, Order
Forecast, Parameter Optimization, FRP Cleanup with their
frequency definitions in a meaningful way
Impact on: Workload Balance of FRP over the week
Applicability: Forecast frequency as of SAP F&R 5.0, others as of SAP F&R 5.1
Background: It is technically possible to calculate Forecast, Order Forecast and Parameter
Optimization daily; however, it makes no sense as long as the database (consumption history and technical settings) are unchanged. How often and when the forecast for a special location product should be calculated will depend on your business processes and requirements (such as replenishment lead times). Therefore, you can determine both the frequency and (directly or indirectly) the weekday of forecast calculation for a location product or for groups of location products. The same holds true for the Order Forecast Calculation and Parameter Optimization.
FRP cleanup deletes obsolete data from the FRP files. It can be scheduled for specific weekdays and a number of weeks indicating the frequency on the location level.
All these settings are maintained in the FRP Process Control Profile, which is assigned to a location in FRP Administration.
Recommendation: Consider how often these calculations need to be done. Also try to
distribute the workload for these calculations over the week or when the most time is available. For more information regarding Parameter Optimization, seeSchedule the FRP Parameter Optimization…
Implementation: Configuration for all of the above calculations is very similar:
Create frequency profiles (SAP F&R: IMG: Forecasting and Replenishment F&R Processor Maintain Forecast Frequency Profiles or Maintain Order Forecast Frequency Profiles or Maintain Parameter Optimization Frequency Profiles,
respectively)
In the FRP Process Control Profile for the location in question, specify the level on which you would like to assign the frequency profiles: selling class, ABC class, location, or location product. In the first three cases, you can assign frequency profiles to the respective objects within the Process Control Profile itself. In the latter case, you have to assign the frequency profiles using the location product mass maintenance
transaction. You can access the Process Control Profile by double-clicking from the FRP Administration or via IMG: Forecasting and Replenishment F&R Processor Maintain Process Control Profiles)
4.4. Schedule the FRP Parameter Optimization outside the
critical time window
Impact on: FRP runtime
Applicability: As of SAP F&R 5.1 (In SAP F&R 5.0, Parameter Optimization can be
performed on location level only)
Background: The FRP Parameter Optimization provides, among other things, optimized
values for the ‘Adaptivity’ and ‘Resolution’ parameters of the ‘Regression’ forecast method for each location product. For scheduling of the Parameter Optimization there are two general options:
Include it in an FRP sequence; for example, in sequence 3 AUTO_REPL_AND_OPRM right before the forecasting or in an earlier or later sequence
Schedule it as a regular job; it is then completely independent of the FRP run From a logical point of view it makes sense to perform the Parameter Optimization right before the forecasting because the system then has the updated consumption available and can use the optimized parameters for the upcoming forecast. However, the calculation causes increased runtimes. On the other hand side, it should not be calculated in every FRP run and the workload can be balanced over the week (seeSet up and balance …).
Note that the parameters usually will not change dramatically after a first optimization.
Recommendation: If applicable, schedule the FRP Parameter Optimization outside of the
critical time window (usually sequence AUTO_REPL_AND_OPRM) or even completely outside the FRP run.
Implementation: For the scheduling of the Parameter Optimization frequency, seeSet up and balance …. In order to schedule it separately from FRP, use report
/FRE/UI_SAFRUN_CALIBRATION. In order to include it in an FRP sequence, you can either create a new sequence or take a suitable existing sequence and include task
SAFRUN_CALIB in it.
4.5. Divide the FRP run into steps, if applicable
Impact on: FRP workload balancing
Applicability: General, Dispatcher as of SAP F&R 5.0, some of the sequences are only
available as of SAP F&R 5.1
Background: You can perform the FRP run by either scheduling report
/FRE/FRP_MID_BASIC as a job or using the dispatcher function. In both cases, the FRP run is divided in the sequences. The dispatcher profile SAPDEFAULT has the following
sequences:
UPDATE_SUBSTITIONS – Preparatory steps for product substitutions MD_AND_TECH_SYNCH – Update of master data and technical data in FRP TD_DATA_SYNCH – Update of open orders in FRP
AUTO_REPL_AND_OPRM – Stock and consumption synchronization, actual replenishment, exception and order proposal generation
ORDER_FORECAST – Order Forecast Calculation
FC_AND_MD_SYNC – Update of forecast and changes master data in F&R NON_EXC_ANA – Update of analytical data in F&R
FRP_CLEANUP – Deletion of obsolete data in FRP
Report /FRE/FRP_MID_BASIC contains only sequences MD_AND_TECH_SYNCH,
TD_DATA_SYNCH, AUTO_REPL_AND_OPRM, FC_AND_MD_SYNC and NON_EXC_ANA. Further calculations (such as order forecast calculation) can be scheduled as separate jobs. FRP can run ‘all-at-once or ‘step-by-step’. All-at-once means that all sequences of FRP for one location will be performed in one work process without interruption. Step-by-step means that a location might be processed in several steps and therefore several work processes. The latter scenario is especially applicable for store scenarios because of the huge data volumes to be processed in short time frames.
It is possible to split up the FRP run into different steps. You can do this by either using the dispatcher function (see recommendation) or by scheduling different variants of
/FRE/FRP_MID_BASIC (not explained here).
The overall runtime of the FRP run of one location is generally longer in the step-by-step scenario than in the all-in-one scenario. This might be even increased with use of the hybrid solution (see the related topic). However, the critical time window is better used and the workload is better balanced because FRP can start earlier with the preparatory work.
Recommendation: First estimate the processing load and decide whether it makes sense to
split up FPR run into steps to fulfill your business requirements. If so, you can use the dispatcher function to define start times for each of the steps..
Implementation:
Create FRP start profiles for each step (IMG: Forecasting and Replenishment F&R Processor Maintain FRP Start Profiles):
o Step 1: You can perform preparatory measures (sequences UPDATE_SUBSTITIONS, MD_AND_TECH_SYNCH and TD_DATA_SYNCH) as one step prior to POS upload into F&R.
o Step 2: You can then wait for the consumption upload, which can trigger the following step: execute sequence AUTO_REPL_AND_OPRM within the critical time window.
o Step 3: You can later perform further sequences (for example, sequences ORDER_FORECAST, FC_AND_MD_SYNC, NON_EXC_ANA and FRP_CLEANUP)
Assign the Start Profiles to the sequences within the Dispatcher Profile for a location (IMG: Forecasting and Replenishment F&R Processor Maintain Dispatcher Profiles).
Assign the Dispatcher Profile together with Processing Level ‘S’ to the location in FRP Administration (transaction /FRE/FRP_ADMIN - Administration).
Start and activate the dispatcher to automatically start the individual FRP run steps for the locations (transaction /FRE/FRP_DISP_ACT - Activate and Start Dispatcher). If you want to use the consumption upload as a trigger for FRP sequence AUTO_REPL_AND_OPRM, you need to activate the flag ‘FRP Trig.’ in IMG:
Forecasting and Replenishment Interfaces Maintain Time Series Interface for
qualifier 3000. Alternatively, you could use the stock update (qualifier 4000) as the trigger.
4.6. Use the hybrid solution, if applicable
Impact on: Data volume of FRP files, overall runtime of FPR, especially concerning network
load in server group architecture
Applicability: As of SAP F&R 5.0
Background: In FRP Administration (transaction /FRE/FRP_ADMIN) you can choose
between two modes of data storage and processing for a location: ‘Server group’ and ‘Server’. This setting defines where the FRP data is stored:
Server means that the FRP data for a given location is confined to one server -- the
data is stored on a directory of this server and the FRP processing for this location must be executed on this server.
Server group means that the data for the location is stored in a central directory and
FRP processing can be executed on any server in the server group. This allows a better load distribution by dynamic assignment of server tasks in the server group. However, this causes intensive network communication between the server and the central directory while the FRP modules are executed. In particular, if you use an Network File System (NFS) connection, this can cause a significant increase in runtime for the FRP modules. Other access types provide better performance.
In order to resolve this issue with network communication, you can also activate the ‘Hybrid’ solution for the server group. The ‘Hybrid’ solution leads to a compression of the ‘location environments’ (file folders for the location data) using SAPCAR. With server-group architecture, you might have additional advantages because the network load might be reduced considerably: the system reads the location environment in the compressed format only once, decompresses it to a local directory, processes the data locally, compresses it again and writes it back to the central data share. For more information, see SAP Note 909935).
You should also consider additional system load for decompression and compression of the FRP data. Therefore you need to take the following into account:
The relation between number of products within a location and number of locations: the advantage of the hybrid solution is better for a smaller number of large locations The fact whether you run the FRP sequences all-in-one or step-by-step: in the latter case, the system has to decompress and compress the data for each step separately
Recommendation: Compare the runtime measurements to decide whether the hybrid
solution makes sense for your business requirements. Rule of thumb: The hybrid solution can make sense in a 3-tier system architecture, but usually does not (in terms of runtime benefits) in a 2-tier system. If you use the hybrid solution, you should make sure that the local I/O system is properly configured and tuned to be able to run many parallel tasks on the application servers. Judge whether RAM disk might help to overcome potential I/O issues.
Implementation: Refer to the Configuration Guide ‘Multilevel Replenishment’ for FRP
Administration.
4.7. Activate ‘Deferred Checks’ for products without planning
day, if applicable
Impact on: Positive impact on runtime of sequence AUTO_REPL_AND_OPRM, possible
negative effect on overall FRP runtime
Applicability: As of SAP F&R 5.1 SP07
Background: The FRP run is performed for the planning dates of locations, but the planning
date is not necessarily the date on which FRP is running (see FRP Process Control Profile). Only if the products in a given location have a planning day, too (that is, order proposals can be created for them), an actual requirement calculation will take place during sequence
AUTO_REPL_AND_OPRM. However, this sequence first performs special checks (such as
whether the stock is sufficient) not only for the products with planning days but also for those without planning days. These checks require running the requirements calculation to be able to raise exceptions that are needed immediately for the products with planning days, but not
necessarily for those without planning days, at least not at this point in time. If you do not need these exceptions for the products without planning days to be created within your critical time window, you can have FRP postpone these checks to a later point in time, or even cancel their creation entirely.
The situation becomes more complex if you also use the order forecast. Depending on the purpose of the order forecast and when you actually schedule the calculation of the order forecast, you can also decide whether deferred checks make sense for those products that have no planning days but that are relevant for order forecast calculation.
For example:
If you only need the order forecast for information purposes, it is sufficient to calculate it for all products outside of the critical time window, regardless of whether the products have planning days or not.
If you use the order forecast for later aggregation (for example, in a Multi-Echelon Replenishment scenario), you might want FRP to calculate the order forecast during the critical time window for the target locations. In that case, it also requires
performing a requirements calculation for articles without planning days on that date and therefore the “deferred checks” option cannot be used for products relevant for the order forecast calculation.
Recommendation: If you activate the use of deferred checks, you can decide whether the
checks for products without planning day should be postponed to a later point in time (more precisely, to sequence FC_AND_MD_SYNC) or whether they should be cancelled entirely. In addition to activating the deferred checks, you have to decide whether location products without planning days on the planning date in question -- but which are relevant for the order forecast -- should be checked within sequence AUTO_REPL_AND_OPRM or should be deferred. This decision depends on the point in time of the order forecast calculation.
Examples:
If the order forecast calculation happens outside your critical time window, it makes sense to also postpone the check for those products (no planning days but relevant for the order forecast). This means that these products will not be checked in sequence AUTO_REPL_AND_OPRM.
If the order forecast calculation occurs within your critical time window, it makes sense to check those products (no planning days but relevant for the order forecast) already in sequence AUTO_REPL_AND_OPRM.
Implementation: To activate the deferred checks: IMG: Forecasting and Replenishment F&R Processor Maintain Process Control Profiles, choose an option for Location Product w/o Planning Date in Field Group ‘Deferred Checks’. Additionally, activate the Location Product considered by Order Forecast Calc. option if the order forecast does not occur within
the critical time window. (As a consequence, order forecast relevant products without planning days will be deferred.) See also SAP Note 1229777.
5. Optimize SAP F&R outbound and SAP Retail
inbound processing
5.1. Start the outbound processing of order proposals during
the FRP run only if there are free resources in the system
Applicability: General
Background: The FRP run creates order proposals and checks whether they can be
released automatically. Released order proposals are instantly ready for transfer into the purchasing system (such as SAP Retail); that is, you can transfer released order proposals even while FRP is still running for other locations. However, order proposal outbound
processing to SAP Retail requires some system resources because the work processes have to wait until the purchase orders are created in SAP Retail, unless you did not activate the
buffer tables for the order inbound. These work processes are no longer available for other tasks (such as the FRP run).
Recommendation: If there is no urgent need for purchase orders in SAP Retail during the
runtime of FRP in SAP F&R, you should start with the order proposal outbound processing after the FRP run -- or at least the time-critical part -- is finished for all locations.
Implementation: Schedule either an order proposal outbound variant of transaction /FRE/OPM_MASSREL Release Order Proposals Manually or transaction /FRE/BIF -Interface Processing after the time-critical sequences of the FPR run.
5.2. Use buffer tables for order inbound processing in SAP
Retail, if applicable
Impact on: Runtime of order proposal outbound in SAP F&R Applicability: As of SAP Retail ERP 6.0 EhP02
Background: Order proposal outbound processing from SAP F&R to SAP Retail requires
some system resources because the work processes have to wait until the purchase orders are created in SAP Retail. These work processes are no longer available for other tasks (such as the FRP run). Therefore, a new logic and new buffer tables in SAP Retail are available for the order inbound processing in SAP Retail. If you activate this new order inbound logic, SAP Retail uses buffer tables to temporarily store the order proposals that require further
processing in a later step.
Recommendation: If your business requires a fast order proposal outbound processing from
SAP F&R, you can activate the use of buffer tables in Customizing for SAP Retail.
