Item priorities when running planning engine

When I run the planning engine, what are the items which will be planned first? Or, what is the order that NAV is using to create planning proposals for items?

 

Good and very important question. Planning (MRP and MPS) need to be very careful on how items are being planned since proposals might be a dependant demand for another item. This second item then needs to be planned afterwards. So, how is this done in NAV? Using the following priorities:

 

First. Items are ordered by "Low-level". This defines their level on the BOM. In other words, if this is an finished item, "Low-level code" would be 0. Thus, it would be planned first so their planned proposals are considered as dependant demand for items in the next BOM level. If you are curious, this "Low-level code" is defined on the item table and is being calculated when you certified the BOM.

 

Second. Within items at the same level in the BOM (ie. both are finished items), the item number will be used as an implicit priority.

 

Third. If now we are planning and item, this item could be defined at many locations using SKU, correct? In this case, the next priority would be the "Transfer-level code" which is defined on the SKU card. This defines the locations priority on the distribution network (ie. a distribution center needs to be planned first than the manufacturing plants).

 

Fourth. If transfer level code is the same, then location code would be used as an implicit priority. This is similar as with items when have same priorities.

 

So, the above priorities are how NAV orders the items to find their inventory profile and creates planning proposals.

 

But, how NAV prioritizes demands when pegging these demands to the existing stock? This is a topic for next post (I thought it is better to separate the different priorities that NAV considers to better understand the planning).

 

 

Starting Date: NAV 5.0 SP1

We already covered this before. But, lets try to provide further explanations on the changes coming here.

 

With NAV 5.0 SP1 planning engine, inventory stock will be evaluated at Starting Date with these two consequences:

– if  stock on Starting Date is below zero (negative), it forces the stock to be at minimum of zero by creating a planning proposal with due date equal to "Starting Date -1". This guarantees that there is no negative stock on the planning horizon. This will be treated as an emergency order (warning icon). 

– if stock on Starting Date is below safety stock, it forces the stock to be at minimum the safety stock level by creating another planning proposal with due date equal to the "Starting Date". This guarantees that safety stock is also respected. This will be treated as an exception order (warning icon).

 

Another consequence is that emergency (negative stock) and exception (below safety stock) are treated as two different planning lines. Earlier versions this was combined into one planning proposal.

 

It might be a questionable debate here but the intention with the design here is:

– first to ignore any backorder (any order before starting date) assuming purchases are receipt and sales are shipped

– second to assume stock will not be negative on the starting date

– thrid to assume stock will be at least equal to the safety stock level on the starting date

With the three above, planning proposal should provide a more realistic and stable planning proposals (ie. no proposals on the past, no negative stock, …)

Why NAV does not plan changes for some type of orders?

In some circumstances, NAV does not propose changes to existing orders when these could be replan to better suit the demand profile. An example, an started production which can be used to fulfill a demand. In this case, NAV will not change the production order. Why? Because it considers too late to change the production order since it already started. And, what would be other examples of order types which NAV treats the same? These are (as I understood):

– Orders already posted (purchase already receipt, transfer already shipped)

– Orders already in the warehouse

– Orders waiting for approval

– And, the example above production orders with status Started (with consumption or output postings)

 

There could be a debate here on if NAV should or should not allow this. But, the above is the current design. And, I would say that the above could be the better in most of the scenarios having in mind NAV should be the standard.

Reorder items and forecast

Forecast are used to prevent planning of any new demands coming. But, is it meaningful to use forecast with reorder point items? I would say no, just what I think. I am saying this because the reorder point is calculated from the safety stock + average demand during lead time. Thus, the reorder point level intrinsctly have a forecast on what would be the demand (the average). Thus, it is not meaningful to include forecast when reorder point is used.

How to calculate reorder point in NAV 5.0 SP1?

Have you realized NAV 5.0 SP1 provides a design change where reorder point items can now use reorder cycle? Yeap, based on the design this is to provide stability to planning proposals. But, lets start first on trying to understand what is this reorder cycle for …

 

In prior versions before NAV 5.0 SP1, reorder cycle was a planning setting used for "Lot-for-lot" items. These items have the possibility of grouping demand when creating a replenishment supply. The idea is to group existing demands when ordering a new replenishment. Based on this, a replenishment can be used to satisfy multiple supplies. This is in opposite of "Order" policy items where one and only one order is being fulfilled with one and only one supply. Back to "Lot-for-lot", the time period on how long does the planning look for existing demands to group into a replenishment is the reorder cycle. Based on this, if we had (for example) a reorder cycle of 7 days. NAV will group the demands within the next seven days (if there are any) when creating a replenishment. Please note, this was only used/enabled for "Lot-for-lot" items.

 

Now, in NAV 5.0 SP1 this could be used also for reorder point items. The idea is to provide stability to the planning proposals instead of letting the planning engine to create proposals one after the other. Based on this, the planning engine will check if there is any point of time where stock is below reorder point level. If so, it will plan a replenishment at the end of the reorder cycle instead of creating the replenishment when stock goes below reorder point (as previous versions does).

 

However, how do we need now to calculate the reorder point in NAV 5.0 SP1? Theoretically, reorder point is equal to the safety stock plus the average demand during lead time. This is to have guarantee that reorder point will make to stock at least equal to the reorder point when reorder replenishment comes. But, will this be the same calculation in NAv 5.0 SP1? No, very good question. No. With NAV 5.0 SP1, the replenishment will not be triggered when stock goes below the reorder point. It will be planned at the end of the reorder cycle. Thus, the lead time to get the replenishment in our facilitates is greater than in before versions: we need to wait until the end of the reorder cycle and we need to wait for the lead time as well. Thus, reorder point now should be calculated like safety stock + average demand during lead time + average demand during reorder cycle (or part of it).

Frozen period: Planning Order Date vs. Starting Date

Very interesting change in NAV 5.0 SP1 … Order Date (in planning worksheets options tab) is renamed to Starting Date. But, this is not just a renaming thing. There is a functionality behind this which needs to be understand well. Lets start …

 

Starting Date (5.0 SP1) now defines the beginning of the planning horizon versus Due Date (earlier releases) where this was the date where reorder point was being evaluated. What does it mean? In NAV 5.0 SP1, if there are demands and supplies before the Starting Date, these will be just ignored and will not propose actions to them. In other words, it will not be planned since they are assume to be already shipped or in stock. Strong statement, correct? But, there are exceptions to this rule (always are exceptions):

– If the projected available inventory on the starting date is zero. Mmm, ok, that is good. So, it will ignore those orders unless there is a violation on the quantities and whatever we had in inventory is not enough.

– If there are order-to-order supply/demands or serial/lot numbers. The reason is that if I have a M-T-O demand, the specific supply must be planned to ensure the demand can be met.

 

Now, lets try to view this functionality from an overall perspective. First, lets try to re-phrase this functionality: Demand/supplies before Starting Date are only considered when there are exceptions (ie. quantity is below zero, specific demand does not match …). Mmm, I don’t need to be worry about this past orders unless there are exceptions, isn’t this a good thing instead of adding these to the overall planning? And, can we use this as a period where plan cannot be touch? Exactly. In many industries, there is a need to have a Frozen period to provide stability to production/planning. I mean, if you are a planner, you are not going to accept a change for any inmediate date since there is not much we could do to replenish this: there is no time to react. Thus, you will be targetting for this functionality. Also, this frozen period is expanded with the above exceptions which are valid to alert the planner when something is not planned properly. These exceptions will be planned as emergency order with due date the starting date (need to be available by then).

 

My suggestion on how to work with this would be to use this functionality to freeze the near term (ie. one/two week, one month, depending on businesses). Thus, planning will start from the end of this frozen period. But, of course frozen period need to be analyzed to ensure supply chain requirements are met. This could be done with two alternatives: running the planning only for the frozen period to check where the emergency orders are coming from; or, creating a small report that compares Projected Available Inventory whenever there is a backdate sales so it can allow us to better understand the impact of these exceptions. This frozen period planning should be (ideally responsible) of a planner which also could have visibility of the capacity "holes" available for other orders. But, reader should understand this frozen period planning should done to check exceptions. It might be the case some of you could claim that there is no way you could know what sales in the are late if they are not planned (and no action suggested). Again, these are exceptions. Having a small report or running the planning for the frozen period (create a worksheet template for the planner responsible) should be enough and it is better than adding all these to planning which will "disturb" the results. 

 

This functionality can also understood what some people call to Firm supplies (check my earlier post in this blog about Fix vs. Firm supplies).

Items with reorder point policy defined should not use reservations

If you are planning using a reorder point policy, you should not use reservations as a general rule. This should be a very exceptional process. Just my opinion, as simple as that. But, let me try to explain why I consider this.

 

First of all, a reorder point policy is intented to plan against stock. Based on the safety stock and reorder point levels that we might consider from our business rules, the planning will propose actions where any of these two (safety stock, reorder point) are violated. So, my personal feedback here is that whenever you have these kind of items you should just let the system work … and, you should do not disturb the system with "reservations". Reservations are more likely a M-T-O than planning against stock replenishment. Also, if there are reservations with items planned against stock, this will add "noise" to the planning results. This could be very well understood in an scenario where there is a demand later in future which is being reserved. In this case, the projected inventory is acceptable if another sales comes earlier but, quantities are not available since these are reserved for the sales with later due date.

 

Better to provide an escenario:

– Item is using "Fixed Reorder Qty."

– Inventory is 50 pcs

– There is a sales order for 30 pcs on Dec 1st

– You decide to reserve 30 pcs from stock to this sales order

– Later, a new sales order comes in for 40 pcs on Nov 15th.

 

When you plan what will it happen? On Nov 15st the available inventory is -20 (stock – reservations – gross requirements = 50 – 30 – 40= -20) while it is not below the reorder point (the inventory is in stock so it does not go below reorderpoint). In this scenario, a planning proposal is created with due date Nov 15st and will do a backward schedule from it. In NAV 5.0 SP1, this would be what it is called an Emergency order. If you think about this, it should not be an emergency, correct? But, is NAV working properly? I know, you might think NAV should not behave like this and this could be reasonable. But, is NAV the issue? Or, is the reservation against a late in time demand the real issue? I would say, the reservation is the issue since it is not good business practive in any planning stock situation.

 

As a side note, there are exceptions where reservation need to be used, of couse. But, not as a general rule. Thus, having "Reservation= Never" in item card while reordering policy is "Fixed …" or "Maximum …" makes me think that there is something on the business process which is not handled properly (ie. do you have too many last minute orders or emergency orders? …). Again … just my opinion. 

Single UoM vs. Multiple UoM

This time, this would be a short entry in this blog: if you are using multiple UoM, you should be using at least Bin Mandatory. Moreover, most of the customers would need to use WMS as well.

 

As always, a bit of business background here. Asume you have multiple UoM, how will your warehouse look like? I would say you wouldn’t mix the different UoMs in the same warehouse space (or Bins, in Dynamics NAV terminology). At least, this should not the business scenario in your company if you are looking to boost your productivity. Thus, you should be organizing your warehouse in the sense different UoM are located in different warehouse spaces (different bins). Reader should already got my point here: multiple UoMs means "Bin Mandatory" in Dynamics NAV must be enabled.

 

What would happen if you are not truly using "Bin Mandatory" when different UoM are defined? Your stock in the warehouse will have different quantities for each UoM (ie. there are 10 pcs,  and aso 5 Boxes, and … whatever). In the other hand, a sales order is coming for 1 BOX. How will Dynamics NAV reduce the available stock? Will it reduce from the available stock in Boxes? Or, will it reduce from the pcs available? The answer is in the cost method. Cost method defines the application logic (ie. if FIFO application will follow a First In First Out rule). Thus, there is no guarantee the stock will be reduced from those quantities available which have same UoM as your sales order does. Thus, best thing is to use Bin and define in the Sales order from which Bin you want the stock to be taken (BOX or Pcs in our case).

 

In the other hand, why do we need WMS? If you are using Change UoM functionality from a pick document and you would like to use this functionality, you must be using WMS since this "Change UoM" is not working in all scenarios of a basic warehouse.

Default Safety Lead Time: an overlooked planning parameter

This time, lets talk about "Default Safety Lead Time" parameter which is available in the Manufacturing Setup and Planning tab in Item Card.

 

First, what is this setting for? Well, the name is very representative: this defines the default time which will be added to the lead time (purchasing or manufacturing) of a given item. In other words, this setting is an added time to guarantee items will be on time. In some circunstances (not so many since planning needs to be accurate), there is a need to add some time by default to the lead time to ensure deliverables are timely. As an example, there could be manufacturing lead time of 10 days. But, planners also would like to add a buffer period in case of delays, thus they will be using Default Safety Lead Time to define this buffer period which will be added to the lead time.

 

As readers can note, I believe this is a constantly overlooked parameter in Manufacturing as well as Planning setup. Why? Many times, we define an Item with Make-to-Stock policy. Thus, item will be planned against stock with no regards of what are the current demands (unless, demand means item will go below safety stock level). Now, we combine this with the "Default Safety Lead Time". If we define this, assume setting is set to 1D for instance, it means that replenishment to avoid sotckout will be planned one day before than when this will happen, it will be planned at the end of the ealier working day of the stockout. Following this case, some times users feel their item lead time are accurate and good enough for not defining a "Default Safety Lead Time" in Manufacturing nor Item Card. What does this setting mean in this case? Well, this mean the stockout replenishment will be planned at the very same time/hour when stockout is plan to happen. Is this correct. I would say no. That is just my opinion. I am saying this based on two reasons:

A. ERP is a planning system which cannot be taken as an scheduler. This means, the planning proposals cannot be taken or considered with hours and seconds. No. Time proposals from an ERP should be bucketized in days and the capacity (start and end of a production) should be only considered within a given day not within a given day and time.

B. If users are planning against stock, the replenishment of the stockout cannot use hours are seconds, or will you consider a make-to-stock reordering policy is feasible if it considers at the very moment when stockout will be done? Having in mind APICS, stockouts need to be replenish the day before they are planned to happen since it will be difficult to guarantee that stockout will actually happen on a given day, hour, minute and second. An ERP cannot guarantee this.

 

Thus, if Make-to-Stock is defined, the "Default Safety Lead Time" is mandatory. In other case, I believe users need to plan one replenishment after the other, one production/purchase order after the production which originates this demand, users need to plan with no buffer lead time=with no safety leadime. If this is the case, I might say users does not plan with "Make-to-Stock", they are planning with "Make-to-Order".

Concurrent capacities

Concurrent capacities is a setting available in the routing card. With this setting, customers could define how many resources (machine) could work simultaneously in a given operation. In this case (resources working simultaneously), the operation time will be reduce due to the fact that concurrently working hours are being used for this operation.

 

What is the premise to have this working? It must be available capacity to be working simultaneously. In other words:

– if this is a workcenter with consolidated calendar, there must be enough machines with enough capacity linked to this operation to work concurrently.

– if workcenter is not consolidated with machines calendar, the capacity in workcenter card must be greater than 1.

 

To summarize, concurrent capacities:

– produces that operation time is being reduced due to the fact concurrent machines are working on the operation

– capacity consumed is the same as if there is no concurrent capacity defined

– this need to be consistent with the capacity available (consolidated machines capacity, or workcenter capacity).