Priority Range methodology on Planning Priority Model with Planning Optimization

Posted by

In the previous post I’ve introduced the new Priority base planning feature and how the priority is calculated with the percentage of maximum inventory method. In this post I will focus on the product range approach which can be applied instead on the Planning priority model.

The priority is not calculated by a percentage but defined by thresholds.

Source : Tech Talk

As you can see above, there is 4 thresholds to setup. Depending of the quantity of the projected on-hand, there is 4 priority to define :

  • 0 or less : high priority for replenishment (in this case, with the value 1)
  • < minimum : strong priority
  • > minimum and < Reorder point : medium priority
  • > Reorder point (until maximum) : low priority

For my example, with my Min/Reorder/Max quantity of :  10, 30 and 100, my setup is :

  • Priority 1 : 0 or less
  • Priority 30 : 1 to min (10)
  • Priority 50 : min (10) to reorder point (30)
  • Priority 70 : reorder point (30) to max (100)

Single supply with most important quantity

The Planning priority model has to be setup with the Priority Range value of the Priority calculation method. By doing that, there is much more setup available than the percentage of maximum quantity method.

To start, you will have to choose for the Planned order creation value. In the first scenario, I’ve put the Single supply with most important quantity.

Under the Planning priority ranges tab, I’ve setup the thresholds. Let’s have a look.

  • From qty : Lower limit of the planning priority range (generated automatically based on the previous range initiated)
  • To qty : upper limit of the planning priority range
  • Percent of to quantity : allocate x% of the min/ROP/Max of the coverage item

In addition, you will need to allocate the appropriate Planning priority models to the coverage groups. In my case, I’ve just updated the existing coverage group for my demo purpose.

Then, I’m running again the Net Requirement for my previous sample data, and I can notice few changes regarding the priority calculated.

The sales order is still on the priority 5, as it’s setup directly on the sales order line and hasn’t change.

The 2 transfer orders are now with a priority of 50 each, instead of 20 and 10 (calculated according to the percentage of maximum inventory).  The stock is currently between the minimum and the reorder point that’s why the priority is setup to 50.

The planned purchase order has been calculated with a priority of 1 as the stock on the DC warehouse is 0 (actually I haven’t setup any min / Reorder / max for warehouse DC).

Split according to priority range

Now, I will change Planned order creation value and test the split according to priority range. Only this setup has change and the rest of the demo sample stays as it is.

The consequence will be a split of the orders according to priority ranges. The engine will break the quantity that belongs to each priority range into its own requirement and will use the priority value  or the priority range to sort the planned orders.

Let’s run again the Net requirements for the item.

The 2 tranfer orders have been split :

  • Quantity of 80 : split in two orders, one of 10 for reaching the reorder point (with a priority of 50) and one of 70 for reaching the maximum (with a priority of 70)
  • Quantity of 90 : split in two orders, one of 20 for reaching the reorder point (with a priority of 50) and one of 70 for reaching the maximum (with a priority of 70)

It’s more precise and priority are highlighted per threshold for planned orders.

Consider demand priority

The last option to investigate is the Consider demand priority. You can see the exact definition in the screenshot below. To rephrase it, it’s a more detailed and precise split that is done regarding the priority and thresholds.

By running the Net requirements, let’s comment the results.

Another split appears, applied to the planned purchase order for warehouse DC. The other transactions generated remain the same as previously.

The explanation of this split :

  • 142 unit are missing so there is need for a purchase order of 142.
  • Having 40 on-hand, the first 12 are allocated to the sales order (priority 5). 28 are still available.
  • 10 are allocated to the transfer order (priority 50). 18 are still available
  • 20 are allocated to the transfer order (priority 50). -2 are available so the planned purchase order for a quantity of 2 has been generated with a priority of 50
  • 140 are allocated to the transfer order (priority 70) justifying the planned purchase order of 140 with a priority of 70

That’s it for the Planning priority feature.

It the following posts, we’ll introduce the DDMRP feature.

Yohann

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.