The main purpose of requirements planning in retailing is to guarantee article availability in a retailer's sites, considering the need to both optimize the service level, and to minimize costs and capital lockup. By continuously monitoring the stocks, the requirements planning process is set up to automatically generate procurement proposals for purchasing. Requirements planning is regularly performed on article/site level.
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.
In order to set up requirements planning on article/site level, requirements planning and forecasting parameters are set in the logistics views (DC, store) of the article.
The (material) requirements planning type (RP or MRP type) plays a key role in requirements planning. For example, it controls whether a forecast is mandatory, optional, or not relevant. You also assign a lot sizing procedure, and the responsible MRP controller (stock planner) among other settings.
Forecast parameters are used to define the time interval of the forecast (period indicator), the number of historical values used, the number of periods forecast, and so on. The period indicator also determines the time interval for updating consumption values in the system.
The following forecast models are typically used:
Seasonal trend model
Each of these forecasting models requires a certain minimum number of consumption values. New articles can make use of the historical values of another article for a certain period of time.
Various consumption-based requirements planning procedures (RP procedures) are useful for retailers:
Reorder Point Planning
In this requirements planning method, the available stock in the warehouse is checked against the reorder point. If the stock available in the warehouse is less than the reorder point, the system generates an order proposal (purchase requisition).
If a vendor always delivers an article on a specific day, it makes sense to capture this day using a delivery calendar (delivery cycle). To define the relevant order day for the article/site combination, a planning calendar (planning cycle) has to be maintained.
Forecast-Based Requirements Planning
Forecast-based requirements planning is also based on article consumption. Future consumption values are forecast. These values are used as the required quantity for the planning run.
In reorder point planning, the site’s currently available stock is checked against the reorder point. If the stock available is less than the reorder point, the system generates an order proposal (purchase requisition).
The reorder point is calculated using safety stock and the expected average article consumption during the replenishment lead time. As a result, the safety stock, existing consumption values, and the replenishment lead time must be taken into consideration when the reorder point is defined. In automatic reorder point planning, the forecast run calculates the reorder point, in manual reorder point planning, the responsible user specifies the reorder point manually.
Safety stock is used to cover unexpectedly high demand during the replenishment lead time and the additional article requirements when deliveries are not on time. Previous consumption, future requirements, and vendor delivery reliability must therefore be taken into consideration when calculating safety stock.
The replenishment lead time is calculated using the following data:
Purchasing department processing time
Planned delivery time
Goods receipt processing time
In time-phased planning, a planning cycle (planning calendar) has to be maintained. For the dates specified, the system then regularly calculates the requirement for the relevant article/site combination. If a vendor always delivers an article on a specific day - for example, each Friday - it makes sense to specify this in an additional delivery cycle (delivery calendar). Time-phased planning then considers both calendars.
In order to use time-phased planning for an article/site combination, the RP type for time-phased planning, the planning cycle, and usually also the delivery cycle have to be specified in the article master (logistics view). The planning calendar is entered in the Planning Cycle field. You also define the planned delivery time, and the exact lot size as the MRP lot sizing procedure (EX: static procedure, lot-for-lot order quantity).
Articles that are procured for the sites using time-phased planning are assigned a planning date in the planning file. This date is set when an article master record is created, and a relevant MRP procedure is assigned. The date is reset subsequently after each planning run. This date corresponds to the day on which requirements planning is to be carried out next for the article and site (MRP area). It is calculated on the basis of the planning cycle entered in the article master record.
This means that automatic requirements planning is scheduled to run for an article and site (MRP Area) on exactly those days.
In contrast to consumption-based planning for regularly available merchandise, the demand planning for seasonal merchandise requires a different planning approach. In this context, retailers who work with generic articles and their variants, are able to maintain so-called Planned Independent Requirements (PIRs) for these article categories to define the future demand. A PIR contains a planned quantity for each article or site for a specific time horizon - for example, one month. PIRs are then considered in an MRP run along with already existing sales and stock transfer orders, as well as existing stock.
PIRs can be created manually, or using the interface from SAP Assortment Planning, or other sources.
A requirements planning run results in a number of purchase requisitions being generated.
The requirements planning run for one or more sites and articles can be executed online or as a scheduled background job, using the Material Requirements Planning (MRP) function. The MRP Live transaction can be used across industries, and thus offers a wide range of requirements planning functions for production planning scenarios, as well as for consumption-based planning. The MRP Live run is executed for MRP Areas. This means that MRP Live requires a site to be defined as an MRP Area. It is also possible to create MRP Areas for a site's storage locations, and for subcontractors, but this is rather relevant for production processes. The planning run is always executed on site-level, not for individual sub-MRP areas defined for a site. The MRP Live transaction can only be used for articles/MRP Areas which have a planning file entry. A planning file entry is automatically created by the system when the relevant MRP settings are maintained in the article master (logistics view). The requirements planning transaction MRP Live provides a comprehensive initial screen for a detailed selection of the articles to be planned, as well as for setting control parameters:
Defining the Planning Scope
In the subscreen Planning Scope, you can select the relevant articles and sites for the planning run. It is also possible to select the articles/sites by the responsible MRP controller. The subscreen, Also to be Included in Planning, is mainly relevant in the Production Planning environment.
Setting Control Parameters
The Regenerative Planning indicator controls that the system plans all articles, for example, also all variants of a generic article, irrespective of whether they have been changed in relevance to the MRP since the last planning run. This means that if the indicator is not selected, the system executes net change planning. The Planning Mode controls, if unfirmed procurement proposals from the last planning run should be re-used if they completely match the new requirement, or if they are deleted and re-created.
The requirements planning run’s available-to-promise (ATP) check considers the current stock and existing documents (for example, purchase orders, or sales orders), using them as planned goods receipts and issues.
The MRP Live run is usually scheduled as a background job. No SAP Fiori app exists for this function.