Grouping demands to one production order

Dynamics 365 Business Central/NAV User Forum
1

Hello,

I’m struggling to find the right setup for following scenario in NAV 2009 SP1 (6.0)

Item is ordered simultaneously by several customers.

Production is running in one batch producing whole quantity that is then splitted for ech customer order. The batch is usually increased to produce some additional quantity in order to build the stock level up so that the next orders can be served from stock.

The item X is set with:

Reordering policy: Lot-for-lot

Reserve: Optional

Order Tracking: Tracking and Action msg

Reorder cycle:1M

Safety stock Qty: 10.000

Inventory: 0

Three Sales orders entered for

X1=100 units

X2=200 units

X3=300 units

Running the Planning worksheet / get action msgs populates two lines with different Production order numbers filled in, first for 10.000 units and econd for 600 units.

Desired output is to have one production order of 10.600

Make-to-stock or Make-to order seem to make no difference.

If order is adjusted on one of the orders sugested and I accept Action messages (ignoring one of thetwo orders), I can have production order with the correct quantity. On the next plan calculation engine suggests qty to be changed back to original qty of 600 units and to issue new one for Safety stock level defined.

Even if the suggested actions are not accepted, the order tracking seem to get lost on the production order and sales orders.

Any ideas for this to get work and production order to cumulate demands of sales orders AND stock replenishment to defined level??

2

hi Johan

The issue is with how NAV treats safety stock. It gives safety stock (or re-order level) requirements as highest priority.

What tends to happen in the field, is that the MRP regeneration is calculated with a fairly wide starting and end date, perhaps 01/11/11 through to 30/06/12.

Any safety stock or ROL requirements are then deemed to be required at the earliest possible date (in this case 01/11/11).

with you re-order cycle of 1M, the system is then trying to match supply and demand into 1M buckets. The first month, from 01/11/11 through to 01/12/11 has a demand of 10,000 units, caused by the safety stock. The second month from 01/12/11 to 01/01/12 has the demand for the 600 off on sales orders.

So, the system then suggests a new order for 10,000 and a separate new order for 600.

So, if you want the message to be a single message for 10,600, the simplest way to do it is either to bring your starting date within 1M of the demand for the sales orders, or alternatively you could increase the time span of the 1M reorder cycle.

BUT (and it is a big but), subject to your oldest production orders, then bringing the starting date in may not be an option (particularly if components can be stolen from an old production order in order to make something else - what happens in this scenario is the component demand disappears from your planning horizon)

Second BUT, if you increase the width of the reorder cycle, be prepared for a negative cash flow impact. IF you needed 5000 in Jan and 5000 in Feb, having a 2M reorder cycle would result in a message for 10,000 in Jan.

hope this helps

Kryt.

3

Hi Kryt,

thank you for your suggestion, I’ve tested but it seem that in our case the lines are splitted because of something else… I actually just set this up in a test environment getting this strange results. The start of planning run is definitely within the time bucket for all items.

All items and both demands come fro the same location and the same variant (being BLANK).In production environment we use variants but the test is not using them.

What I noticed is that each stock replenishment comes with due date that is identical to the start date of the planning run. Starting date-time I do get calculated less 5 days which is default safety leadtime setup.Planning run startin today (24.1.2012) with span to 31.12.2012 therefor give an extra error message

Attention: The Starting Date 16/01/12 is before the work date 23/01/12. (ok system is trying to calculate when to replenish and with 5D safety leadtie this would mean to order in the past, clear).

When running few days in the future, this is gone and only the

Exception: The projected available inventory is below Safety Stock Quantity 9,000 on 06/02/12. (This exception is shown in both cases anyway)

But there are two lines : one for replenishment, one for the customer order line.

Tracking information is interesting:

Have an item setup as above, safety stock 1000

Have an oder line for 250 (dly early feb so within 1M cycle)

Two lines come up in Planning worksheet, one for 1000 (replenishment, with above information messages) from whic I can track back to COL, untracked 750 left.

The second line shows 250 (COL qty) is prepared by the system to Accept action message (tick) But no tracking (!?).

Each line shows a different production order number prepared…so If both released, there would be one quantity of the ordrerline much, notebaly identical item not grouped (which is what we can’t handle well unfortunately)

I’m really confused what is happening there. I’ll need to test this in Cronus as this is backup of our system and I know there has been a lot of customisation, but the planning part has never been used and even setup so I anticipate it is standard… [:$]

4

If you are not using SKU’s can you please set the components at location field in the manufacturing setup to be your main warehouse, or frankly anything except blank. Then re-run and see whether you still have two lines.

5

No, SKU’s not setup. I’ve found this advice of yours earlier last week on this forum already so this is not causing this unfortunately. [:S]

My parameters are Current production forecast, Use Forecast on location both BLANK

Safety leadtime 5D as mentioned.

Combined MPS/MRP- TRUE

Components at location : FINSTOCK

and some dampeners…3D/3%

6

It is nearly 5 years since I have looked at this so I will let Kryt come back in, but I would suggest two things:

  1. Remove the dampeners to see if this is impacting.

  2. Change the order policy to “Fixed Reorder” and see what happens. (You could also move the sagety stock figure to the reorder point during this).

7

I’m do not believe that you can achieve what you are trying to with a LOT-for-LOT reorder policy. The system will treat the safety stock as a priority above order demands, as part of the calculation within the “Inventory Profile Offsetting” codeunit once the first priority stock demands are met, the system moves onto the next priority and so forth.

What you want is for the safety stock to be included with other demands (which is a perfectly sensible thing to request), but NAV will not handle the two together, but will give you separate messages.

Personally, I think this is wrong (from a development logic versus real life point of view), but that’s what it will do.

If you want the two grouped, then you can have your development partner work on modifying the MRP codeunits (which are possibly the most lengthy bits of code to try and pick your way around in NAV), or come up with another solution.

As AdamRoue has suggested the “fixed” reorder policy which is a safe bet (frankly there are fewer planning parameters used with the fixed reorder policy and therefore I think the NAV code is better equipped to deal with it).

If fixed policy doesnt work for the organisation, then what I would potentially throw out there as a possible solution is to have a subsequent “clean MRP messages” function/report, which allows the MRP messages to generate as per NAV’s logic, but then have something additional to that that allows new messages to be aggregated etc.

I think the biggest challenge with NAV’s MRP is that it has not had a lot of real usage (i.e. 100,000 companies using it day in day out). So, it hasn’t gone through the same level of issue reporting as other areas of the system, and therefore is a little weaker than other parts of NAV.

It is very easy to spend time playing with all of the parameters within NAV, trying to get the output message(s) that your human brain would expect/like to see, but once you change the input scenarios (dates, order quantities etc), you’ll find this all shift again.

If you are able to use an order or fixed policy, life may get a bit easier, or failing that I would recommend building a MRP message tidy up function.

(This also allows you to build up some of the user logic, which NAV would never expect to have within it)

sorry that’s possibly not the answer you were looking for, but happy to offer any other help I can

Kryt

8

I’m do not believe that you can achieve what you are trying to with a LOT-for-LOT reorder policy. The system will treat the safety stock as a priority above order demands, as part of the calculation within the “Inventory Profile Offsetting” codeunit once the first priority stock demands are met, the system moves onto the next priority and so forth.

What you want is for the safety stock to be included with other demands (which is a perfectly sensible thing to request), but NAV will not handle the two together, but will give you separate messages.

Personally, I think this is wrong (from a development logic versus real life point of view), but that’s what it will do.

If you want the two grouped, then you can have your development partner work on modifying the MRP codeunits (which are possibly the most lengthy bits of code to try and pick your way around in NAV), or come up with another solution.

As AdamRoue has suggested the “fixed” reorder policy which is a safe bet (frankly there are fewer planning parameters used with the fixed reorder policy and therefore I think the NAV code is better equipped to deal with it).

If fixed policy doesnt work for the organisation, then what I would potentially throw out there as a possible solution is to have a subsequent “clean MRP messages” function/report, which allows the MRP messages to generate as per NAV’s logic, but then have something additional to that that allows new messages to be aggregated etc.

I think the biggest challenge with NAV’s MRP is that it has not had a lot of real usage (i.e. 100,000 companies using it day in day out). So, it hasn’t gone through the same level of issue reporting as other areas of the system, and therefore is a little weaker than other parts of NAV.

It is very easy to spend time playing with all of the parameters within NAV, trying to get the output message(s) that your human brain would expect/like to see, but once you change the input scenarios (dates, order quantities etc), you’ll find this all shift again.

If you are able to use an order or fixed policy, life may get a bit easier, or failing that I would recommend building a MRP message tidy up function.

(This also allows you to build up some of the user logic, which NAV would never expect to have within it)

sorry that’s possible not the answer you were looking for, but happy to offer any other help I can

Kryt

9

Hello Kryt and Adam,

thank you both for your valuable input and comments. Adjusting the dampeners made no difference, the replenishment suggestion message comes out still separated from the Sales order demand.

Fixed reorder policy is not an option for our business unfortunately, we really need to group all the demands together before production is started. The time bucket an dlot for lot is perfectly matching our needs (the roduction runs in one batch yet the produced quantity covers sveral orders and at the same time it may produce some extra for stock replenishment so that the next orders can be satisfied from stock)

The Supply Planning in Microsoft Dynamics NAV 2009 SP1 whitepaper is even using this as example (p.39, Variable reorder Quantity Method) ie. but after some days of thinking about it, safety qty is not actually what we should use as we want for some items to allow for stock to be built up when production runs (the qty we can calculate from the past sales, basically forecasting fro next 2 month projected demand), but in our case we then allow the stock to be consumed even to zero, or replenish it back to projectd sales level when next production runs. With safety stock I’m afraid planner would be getting “qty below safety level” messages every time on his/her daily planning runs as soon the first next demand is supplied from stock and inventory level drops below safety.

So we probably need to keep this outside of NAV, manually adjusting the production order quantity to increase for the desired stock replenishment, having planning flexibility to None else at next planning run this would suggest to reduce the PrO qty.

Kryt, is “clean MRP messages” function/report something available in NAV or your suggestion for development by our partner to deal with this situation? Was looking through docs and help but found nothing about this. I think it is how you would suggest to deal with it when developing a custom soluton but not certain.

Thank you both again! Johan

10

The fixed reorder policy will group demand, it just uses the reorder point as the trigger and not the safety stock. Set the reorder point to zero and the time bucket to 1000D and see what happens. There really is limited difference, from memory, between a fixed reorder point with 0 reorder level and the lot for lot with no safety stock.

White papers are written prior to the software developmentor whilst it is in progress, once the software is released trust the software, the white paper should have caveats everywhere in it, so it is not really a good reference.

11

That was it Adam!

Fixed reorder is what we should use. It was not clear to me from all the docs studied that this reorder policy would group the demands for our mostly MTO business, but it does and also deals with stock levels build up as required.

Thank you for pointing me the right direction!

Johan

12

Hi Johan,

I am a beginner in NAV and I am trying to solve different real time scenarios. I read your scenario and I find it a little difficult to understand the problem that you are facing in running the planning woksheet and so forth.Can you please explain me the methodology in carrying out the planning worksheet as I have no clue on how to do it.