Retail mass merchandisers typically have very large item catalogs (100,000+ items) and most items are replenished automatically via master planning.  Often, the client is expecting a single transfer order per store, and each store is picked on a specific day so this must be accounted for when setting up automatic firming. Buyers also will want purchase orders created only if the items on the PO meet a certain minimum for the vendor. Retail mass merchandisers also have very large item catalogs and many retail locations, which can result in performance issues from the sheer volume of planned orders. This first installment will review the setup and configuration recommended for a mass merchandiser, as well as some additional performance considerations. Part 2 will review functionality used to ease the burden of setting items up for master planning and provide additional efficiencies.

Setup and configuration

Retail merchandisers have some challenges that will require master planning setups that are different from a manufacturing implementation. While this is not all of the parameters that may need updated, it should serve as a good starting point. The setup guide assumes the user has a high level understanding of basic master planning concepts, and only needs to adapt them for application to a retail mass merchandiser.

Master planning parameters

When configuring master planning for retail mass merchandisers, it is likely that all of the distribution centers and stores will be different warehouses under a single site to allow for a single moving average cost for each item (moving average is an industry standard for retailers). To ensure multiple stores aren’t on the same PO, group by warehouse should be enabled on master planning parameters.

To improve performance, caching should be set to “Minimum” since on larger item catalogs with many calendars, it can actually decrease performance. Retailers will typically not use any production items, so the number of tasks in a bundle does not play a significant role in the performance of MRP for a mass retailer.

Use Dynamic negative days should also be set to “Yes”.

Master plan

Master plan default settings are generally useful, but can use some small tweaking. If custom firming is being used, firming time fence can be set to 0 and “Yes” to skip the firming process altogether. Retailers often won’t care about delay messages (transfers will be generated on the store’s day, and purchases will be generated based on vendor minimums with few exceptions). In this case, calculated delays can be set to “Yes” and 0.

The final parameter to be changed is setting the sequencing parameter to “Yes”. This will prevent multiple planned orders from being generated to fulfill multiple requirements.

Item coverage groups

Many item coverage group settings will depend on your implementation as a whole, but for a retail implementation there are a couple of settings I recommend leveraging. To control which day an order for a store gets firmed, I would suggest using a calendar. Planned orders will have requirement dates of only open working days on the calendar. In this way, if you only want an order to be firmed on Mondays, a calendar will be assigned to a coverage where the calendar is only open on Mondays. The item coverage for the store/DC will then be assigned to the coverage group. Any planned orders not filled will have a requirement data of the following Monday.

Below is a sample of how multiple item groups and calendars can be leveraged to meet a warehouse shipping schedule:

As a coverage code, I recommend period for most retail implementations. The coverage period should generally be the expected time between shipments.

An item’s coverage may end up looking something like:

As you can see, the same item may have many different coverage groups assigned to it, but the item coverage wizard only allows the user to enter one coverage group and planned order type at a time. This is where item coverage templates become useful (Part 2), since the user will likely be setting up purchase settings for a few distribution centers, and many different stores with transfer settings. If the implementation has more than a few stores, this isn’t a very scalable tool.

Product lifecycle state

New in version 7.3 is Product lifecycle state. This allows the user to assign a “status” to an item and can be used to exclude an item (or group of items) from master planning. I would suggest something similar to the setup below. By managing the number of items master planning is running for, you can greatly improve master planning performance. This is also an easy way to exclude an item from planning processes without updating many item coverage records if the buyer wants to resume ordering the item at a later date.

Lead time

For purchase orders, lead time is important because it defaults the delivery date when the purchase order is firmed. For transfer orders, it is less important, because the stores typically know the lead time from the DC and will know the day their shipment will arrive. By not defining the lead time, the requirement date will always match the calendar date as well as improve performance.

Lead time can be set to default from the vendor using the lead time field on the vendor setup. When this is used, all item coverages with the vendor will have the lead time defaulted.

The transfer lead time can also be defaulted to 0 based on a parameter in master planning parameters.

Some notes on performance

Due to the large scale of items, it is important the SQL statistics are updated regularly for the following tables:

• REQTRANSCOV
• REQPO
• REQITEMTABLE
• INVENTSUM
• WHSINVENTRESERVE
• INVENTDIM
• INVENTTABLE
• REQTRANS
• INVENTDISTINCTPRODUCT
• REQCALCTASK
• REQCALCTASKSBUNDLE
• REQPROCESSLIST
• REQPROCESSTHREADLIST
• REQPROCESSTRANSFILTER
• REQCALCTASKTRACE
• REQPROCESSITEM
• REQPROCESSLIST

Due to the importance of statistics, delete plan should not run regularly or there is a risk of statistics being based on no planned orders, which will hurt performance (sub-optimal statistics will replace optimal statistics).

As a result of the large number of items and warehouses replenished by a retail mass merchandiser, in order for master planning in around an hour with no standard firming and no delay messages, it is suggested to assume one thread for every 50,000 ReqItemTable records.

Master planning for mass merchandisers has many challenges, and determining the proper setup for an implementation is only the beginning. After the setup is determined, the next step is making the setup of an item’s replenishment easy and scalable for a buying staff that has thousands of items each buyer is responsible. In part 2 of the article, functionality to make setting up an item’s replenishment more user friendly and scalable is reviewed.

Want to learn more about retail planning for mass merchandisers? Continue the series in part 2.

Part 2 ->

To learn more about how you can take advantage of this and other Dynamics GP features, visit RSM’s Microsoft Dynamics GP resource. To make sure you stay up to date with the Microsoft Dynamics Community, subscribe to our Microsoft Dynamics Community Newsletter. For more information on Microsoft Dynamics 365, contact us.

By: Curtis McDonald

Curtis McDonald