Executing Replenishment Planning for Stores

The key process flows covered in the tutorials for this process are to:

• configure and monitor the outbound communication scenario in the SAP Retail system
• select the merchandise data which should be transferred
• administrate and monitor the technical replication

Collecting all detailed POS transactions creates an enormous amount of documents in the S4/HANA system. Example: 1 million store sales transactions with each 10 line items will create 10 million material documents and 1 million billing documents.

SAP Omnichannel Sales Transfer & Audit (SAP OSTA) solution provides an aggregation process, that ensures that all sales transactions from various POS systems are accurately captured, audited, and aggregated to be downstreamed the S4/HANA system. This approach reduces the amount of created documents in S4/HANA systems in an enormous way.

More details can be found in the SAP documentation for SAP Omnichannel Sales Transfer and Audit.

The POS transaction inbound and aggregation process is a critical component of the Omnichannel Sales Transfer & Audit solution. This process ensures that all sales transactions from various POS systems are accurately captured, audited, and transferred to downstream systems.

For the POS Inbound processing the inbound communication scenario in the SAP Retail system has to be configured; therefore the page Communication Management is offered and used typically by an administrator user with administrator roles.

In the area Users for Inbound Communication, a SAP-technical user has been created and assigned. This user is only authorized to post the incoming POS data.

The key process flows covered in the tutorials for this process are to:

• Prepare XML messages for inbound communication
• Maintain settings in the communication system
• Explain the mandatory settings on an API platform

Replenishment is a procedure for the demand-oriented merchandise supply of stores. It is usually scheduled as a regular background job and calculates the demand on article/site level. The demand is determined either manually, by defining a (static) target stock level, or by executing a forecast run (dynamic target stock). Therefore, 2 requirements planning types, Replenish with static Target Stock (RP), and Replenish with dynamic Target Stock (RF), are available. When executing replenishment, the actual requirements are determined using the stock situation, which results from an available-to-promise (ATP) check, and further parameters, such as the planned delivery time. For the actual demand quantity, the system then generates purchase requisitions as follow-on documents. Store replenishment in SAP Retail is executed using the Rapid Replenishment function.

Both a centralized purchasing policy, with ordering autonomy in the hands of the head office alone, and local purchasing autonomy (partial or complete) are supported by the system. It is also possible that store employees review the results of the central replenishment run using the Order Products app, and - if necessary - adjust the quantities before the purchase requisitions are then converted to purchase orders. For example, they must submit their feedback by a specific time of the day (like 10 am), because after that, the follow-on document generation for the purchase requisitions is scheduled centrally. The follow-on documents are either a purchase order to an external supplier, or a stock transfer order to a supplying site (DC), depending on the supply source indicator (other influencing factors for supply source determination may apply, such as source list entries). The supply source indicator options are external procurement from a vendor (standard), internal procurement from DC (stock transfer), or standard before stock transfer, or vice versa.

Replenishment-related settings are made in the Logistics Store view of the retail article master, that is, on article/store level, in the Maintain Article (MM42) app. To use the store replenishment function for an article / store, you specify the requirements planning type RP or RF in the Logistics Store view. The ATP check rule is used to determine the expected stock. The Planned Delivery Time, and (optionally) a goods receipt processing time, are used to determine the delivery date.

With requirements planning type RP, the replenishment requirement calculation determines the current / expected (ATP check) stock and fills up to the static target stock. This means, it determines the difference between current / expected stock and target stock as the requirement quantity, but only, if the expected stock is below the reorder point. It is not mandatory to maintain a reorder point, but it is useful if you want to prevent a piece-by-piece replenishment. It is also possible to maintain a safety stock level. A static target stock level for stores can be used for example for articles with a delivery time within the same or next day (to avoid out-of-stock situations).

With requirements planning type RF, a forecast run is executed prior to the replenishment run. In the master data, a target range of coverage is specified, which defines the number of days - in weekdays - for calculating a dynamic target stock. However, it considers the workdays specified in the logistics (factory) calendar of the store in the requirement calculation. It describes the time span between two goods receipts. Optionally, the calculated dynamic target stock can be increased or decreased by the system using a minimum and maximum target stock figure which can be defined manually. Note: The calculated dynamic target stock value is used for the procurement transactions, but it is neither saved in the article master, nor displayed in the parameter overview.

Forecast parameters are used to define the time interval of the forecast (period indicator), the number of historical values to be considered in the forecast run, the number of periods forecast, and so on. For consumption-based planning methods, like replenishment, the period indicator also determines the time interval for updating the consumption values in the system, for example daily, weekly, or monthly. The requirements planning type determines, if a forecast run is relevant (yes for RF), and if the forecast only calculates the actual forecast values (future demand), or also a reorder point level and / or safety stock level.

The following forecast models are typically used:

• Constant model
• Trend model
• Seasonal model
• Seasonal trend model

Each of these forecasting models requires a certain minimum number of consumption values. If more consumption values are available than the minimum, the system carries out an ex-post forecast to determine the accuracy of the selected forecast model. New articles can make use of the historical values of another article for a certain period, and for new sites, the historical values of another site can be referenced accordingly. The app Schedule Material Demand Forecast Runs (F2464) can be used to execute the forecast immediately as a single run, but also to define a regular recurrence pattern of the job for the selected articles and sites. The forecast for an individual article / store can also be executed manually in the Maintain Article (MM42) app, for example for testing purposes.

The replenishment - related stock levels could be set manually for each article and store, but it is also possible to work with Replenishment Requirement Groups for the mass maintenance of replenishment-related stock levels. Besides a static target stock level, which is relevant for requirements planning type RP, you can also maintain a minimum and maximum target stock level to control the result of the replenishment calculation with requirements planning type RF. Furthermore, you can maintain a reorder point and safety stock level for each requirement group. Requirement Groups (ID and description) are maintained in the system configuration. As an example: a retailer has many stores, which can be grouped according to 3 requirement levels: small, medium, large, depending on their size and turnover rates. For each article, in the Additional Data area, you then define these stock levels per requirement group. Then, you can assign the relevant requirement group on merchandise category level to your stores. This means, a requirement group comprises all the sites who have the same requirements in a particular merchandise category, and who therefore place the same demands on replenishment. Let’s assume, several stores have requirements group "small demand" assigned for merchandise category dairy. For a bottle of milk, "small demand" may mean 40 EA target stock, for a flavored yoghurt article it may mean 20 EA target stock. Both articles belong to merchandise category dairy.

When you save the assignment of a requirement group to a site’s merchandise category, the system updates the corresponding data on article/ store level, that is, in the Logistics Store view of listed stores in the retail article master. If you then change a parameter in an articles’ requirement group, the system updates the Logistics Store view of that article for the listed sites. However, you can also 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 overwritten.

As a replenishment specialist, to directly run replenishment, you can use the Execute Rapid Replenishment (WRP1R) app.

However, usually, store replenishment is scheduled as a regular background job, using the Schedule Rapid Replenishment Run (F5478) app.

In the Scheduling Options area, you choose Define Recurrence Pattern to set the scheduling details, for example, to run replenishment during the night hours.

Rapid Replenishment for retail stores determines the planned delivery date and the current stock. Additionally, in the selection screen, you can define that the ATP check should be used to determine the expected receipts and issues, that is, to calculate the expected stock at the time of goods receipt. You can also define that additionally, the forecast sales from the planning date to the end of the replenishment lead time should be considered. In the app, you can then also directly generate the follow-on documents, that is, purchase requisitions, and the system creates a replenishment run ID, which stores the details of the replenishment run.

In the requirements calculation with dynamic target stock (requirements planning type RF) using forecast values and target range of coverage, the system determines the planned delivery date, and then calculates the requirement quantity based on the target range of coverage.

Example scenario:

• Forecast per week is 100 PC, workdays are Monday – Friday => 20 PC/(work)day
• ATP check result: 0 PC
• Planned delivery time: 1 day
• Target Range of Coverage: 3 days

With that, the delivery day and requirement quantity are as follows for the various replenishment days (Monday - Friday):

In case the period indicator is not the day, but for example the week, and a public holiday occurs on a workday, the forecast demand of the week is split across the remaining days. Using the above example (5 workdays Monday-Friday): if a public holiday occurs on one of the workdays of that week, the weekly demand of 100 PC is broken down to 25 PC/day instead of 20 PC/day.

The processing period of replenishment runs, the replenishment ID (issued internally by the system), the site, or the user who started the replenishment run can be used as selection criteria to analyze the results in the Monitor Replenishment (WRMO) app. It displays information about the items which are successfully processed, and from there, you can also access the follow-on documents (purchase requisitions). Also, items with errors are displayed, for which you can analyze the cause of errors. This app is especially useful to check the results of automatically scheduled replenishment runs (background mode).

The Display Replenishment Parameter (WR60) app can be used at any time for an overview of:

• replenishment master data: RP type (RP or RF), target (static, min., max.) target stock levels, reorder point, safety stock, target range of coverage
• stock information for each article/store
• status information: most recent replenishment run ID, replenishment quantity, replenishment status successful / with errors

For articles with requirements planning type RP, the static target stock (column Target stock) is displayed. For articles with requirements planning type RF, the target range of coverage in days (column TRC) is displayed. The target range of coverage is used to calculate the dynamic target stock during the forecast run.

The key process flows covered in the tutorials for this process are to:

• Maintain forecast and replenishment parameters for articles/stores
• Execute forecast for dynamic target stock determination
• Directly execute, and schedule a rapid replenishment run
• Analyze results in the replenishment monitor
• Check the parameter overview app