Forward-Scheduling on MRP Worksheets

When processing Make-to-Stock items in MRP, Navision sets the Due Date to the Order Date specified on the Regenerative Plan and then back-schedules using lead times/routing times, etc. to calculate starting and ending dates. But inevitably you are told by this that to satisfy the due date specified you should have started making/buying the item several weeks ago! The only way I can see of avoiding this is to set a future Order Date on the regenerative plan – but how far in advance does one do this – you may have items which have a six-month lead time, so entering a date of a month ahead will not help. Ideally what is needed is for the Starting Date to take on the Order Date entered (say, today, or tomorrow’s date) and then future-plan the end and due dates from there. Am I missing something? What do other users do in such situations? Is there another way of planning for future requirements?

Hi Ralph If you forward plan from the point of order date your end item will be planned to be completed months after the demand is required. Ultimately if you have a lead time of six months and demand in one month with no stock, you have to have started it five months ago to meet the demand. I think what you are missing is the individuality of demand. If you are offereing a one month lead time and components have a six month lead time you will need to plan differently for these items than the make-to-stock policy of the parent. If you want to make to stock then you have to offer the customer a six month lead time rather than a one month one.

Thanks for your reply Steve. I appreciate what you are saying and yes, by forward dating the Order Date that is the other problem you get, which is why I’m criticising the system by how it bases everything upon this Order Date. The nature of the business in this instance does in a way have this “individuality of demand” that you speak of. The concept is that there is a central store which is maintained through safety level triggers, etc. working on a MTS policy, and this feeds the production side of the business, under a MTO policy. So for the MTO side of the business, Navision works fine in saying “this is when we have a demand for this item, so work back in time to satisfy this item”. But on the MTS side, we want to say “what do we need to start buying in today, taking into consideration how long it takes to get these items.” I know this is a very simplistic view, of course there are other complications involved, but I’m just trying to find another way of meeting this forward-scheduling requirement.

Hi Ralph It is the 80/20 rule, and probably more than 80 percent of users will want the replenishment to meet the demand. Your MTS policy will have stocking considerations to cover the usage of the MTO environment. You need to balance this stocking to the demand of the MTO environment. The MTS side will have reorder levels etc to cover the usage of the item, so in a perfect world yo uare taking the last MTS item off the shelf when the MTO order requires it, so it is independant of the MTO environment. So from the MTO perspective it is irrelevant how long it takes to get the MTS items, the demand on each is independant. Of course the beauty with Navision is that you can of course modify the system to do what you want it to - just make sure you want I to do that! I feel in this instance the system will perform what you want to too if the items are set up correctly, but I am doiing this myself from a simplistic overview, you will know best!

I agree with Ralph completely. It is as if Navision actually treats everything and Make to Order and not make to stock. Here is another example of the problem I am having: Sales enters an order on Friday, Manufacturing enters a production order due MOnday to cover the need. PLanning now runs and sudggests a new order for Friday. If I accept this, I now have 2 orders for a demand of only 1 item and one is due last week … It’s just not right. I know - I can spend some $$$$ and have the consultants modify my system and then pay them again when I upgrade …

Hi Kevin The system will also suggest you cancel the Monday order, so you are not over stocking. Additionally you can use the dampner settings to deflect these sort of replanning messages but ultimately it is difficult to comment on each individual scenario. Yes Navision may not be perfect for you in every scenario, but with training and the system correctly set-up you should be able to get it 95% of the way at least. This is not a code change, just undersatnding the system and its capabilities - that stays with you, you do not pay for it during the upgrade! Ralph’s issue was that demand was based on the date of the requirement (a concept used by most systems), and his lead times were meaning he had to have placed the purchas order historically, so sales have promised something for 4 weeks time, you do not have key components that are on a 10 week lead time. In this scenario the items with lead times longer than the company default or finished item will HAVE to be held in stock in an attempt to meet customer demand. In this manner you would never get a message telling you you should have loaded a purchase order 6 weeks ago. Ralph had all his policies set to MTO in my opinion and needed to set items as MTS. I have to disagree with your comment on the MTS - Navision will work in a MTS environment, you just have to set it up to do so.

If you are planning to stock, you must make sure that the reorder point is set at a qty that will leave you sufficient stock to cover the reorder lead time. Assuming average usage, you should then never run out of stock because you will reorder far enough ahead that the inventory will get down to zero just as the reorder arrives. You then only get caught out if usage is higher than expected. But even if you do run out, the reorder should still have been placed some time ago and so should arrive sooner than the reorder lead time. Sure, you carry a lot of stock but that is the price you pay for offering a make to order service with short lead times from stock items with long lead times. Cheers John