MRP Planning Bugs

Idleness

Hi

I am really hoping for a little advice.

The Calculate Regen function doesn't work / doesn't behave the same as the net change plan when your items are set for fixed/re-order qty. The inventory level isn't re-assessed when being checked against the re-order qty and as such recommendations have the wrong due date. For some reason the net change plan works slightly differently and can produce the correct answer in certain circumstances.

We were advised by the implementation and support company that this is a recognised 5.0 bug and Codeunit 99000854 Inventory Profile Offsetting update will fix it. Then we were advised that in order to fix it there are many changes required to a lot of code within the system.

Now we are being advised that the code changes are too great and we must upgrade to Navision 5.1. We are 12months into Navision and we have had many issues with item tracking, part shipping, permissions, scanning, MRP it's a very long list that we are finally getting to the end of.

Hopefully I can find out:
1) Are they telling the truth? Is fixing this issue quite so involved?
2) How many issues are there in 5.1 (reasonably major one's not incidentals) that I should be asking for resolution on up front. We were the first company our resellers implemented 5.0 with and we have suffered because of it. I think we will also be the first to take 5.1 with them and I am concerned. We have had some bespoke work done, not a huge amount but they are critical to our business operations.

Thanks in advance for any insight and a big thanks for all the posts already on here. I swear Mibuso has kept me sane during that last 12 months.

cernst

Hi!

Calculate regenerative plan is the best way because it runs the plan from scratch. Fixed reorder qty is the simplest setup for planning and this has been working well since version 3.70. I've not heard about a bug in 5.0 (thats the version you're running right?) but it might be depending on what functions you use in combination with MRP. Stockkping units, tracking etc. You don't have any costomizations that might cause the errors?

In version 5.1 the planning engine has been completly rewritten and because of this there is some bugs in 5.1. In my opinion 5.0 planning function is stable especially when using fixed reorder qty.

Could you provide more info about the setup, is it manufacturing, purchase or transfer orders that does'nt work?

AlexWiley

Well, both functions call report # 99001017, which is interesting. My regenerative plan also seems to be calculating oddly, except when it tells me to cancel an order, it doesn't include that canceled value in the new suggestion production order :shock: . I cannot replicate your issue, but there are a LOT of factors that MRP takes into account so just one variable can create differences.

If they say it is a known issue ask for the write up and get all the information you can about exactly what is not working correctly. Look into the many other planning options available in the system to see if an alternate meets your needs, or at least meets them better than your current tool. If you are getting consistently mixed messages from your VAR, I would suggest talking to someone else- if nothing else just to get a second opinion.

From what I understand, "5.1" is now NAV 2009 and I was not aware it had been released yet. Personally, I don't like to have the first version of anything. That's just so I don't have problems checking my email, so if I am a multimillion dollar company I will be quite a bit more reluctant. It's great to be told your new ERP/MRP system will bake you cookies and tuck you in at night, but as you've seen that doesn't matter if it's not delivered. Demand a native demonstration of exactly what you want before you spend a penny on an upgrade.

ara3n

by 5.1 he refers to 5.0 sp1.

I can suggest a quick dirty solution to confirm that the issue they are tell will be solved in 5.0 sp1. I would make a copy of your db. Import 5.0 sp1 and replace all. If there are tables that error out, try to merge them. This shouldn't take more than one hour.

Then run MRP in this db and see that your issue is resolved or not. If it is resolved, then they can do a proper upgrade/merge. If not, then let me find the real reason.

To find out how many objects will be effected by sp1 upgrade is, in the import worksheet, filter on existing objects modified, and those objects will need to be merged and tested in detail.

I usually estimate 10 to 15 min per object.

Idleness

Thank you for the great responses.

I am running the regen plan with no mps.
@noname - Thanks, We have operationally a single location. An sku card set. The regen plan suggests the correct amount of purchase orders and for the correct quantity (dictated by min order). The problem is the start date, it would appear to nolonger reference when the projected stock balance drops, instead it seems to add the lead time to the previous purchase order suggestion and in our scenario this would be 1 month too late for demand.

However when I run the net change plan (which shouldn't be required) the first purchase order suggestion is for earlier than the regen plan suggestion (which is absolutely correct, the regen plan first suggestion was acceptable but not accurate) and the second PO suggestion is also for the correct date.

I realise this is an involved topic, I hope my details are clear.

@AlexWiley - Thanks, unfortunately production dictate which method they use and fixed reorder should do as they wish, we have had so many problems (some to be expected what with a new system and all) that I just want it fixed...period. We should be able to use the system as defined and fix the quirks but this is more than a quirk. Originally we had some bastardised version of MRP the reseller had built, advised it was a simplified version but it just doesn't work so we are back to core NAV MRP.

@ara3n - Thanks that's great advice. In truth I am hoping it is 5.0 sp1 and I won't take beta software.

AlexWiley

Yes, I absolutely agree changing the method shouldn't be required. I would do two things, as appropirate for you situation/business process:

1) In your test database see if you can move some of the numbers in your setup to generate the proper responses. For example, if you change your lead time from 1 month to 2 months does it remove the problem of product on POs arriving a month late?

2) If the mistake is always the same a developer should be able to change the calculation without much of an issue. This report isn't posting anything, only making suggestions. The developer should be able to write out exactly how the report is calculating it's values and change it to meet the requirements of your business.

cernst

You're setup doesn't look complicated. Can you try to do the same thing in a standard database in company cronus to see if you get the same result? Then you'll know if it's a bug in the system or if some one has messed up the code.

Idleness

@AlexWiley - Thanks, 1) Has been done, but it is always the same, the PO qty's are correct but the suggestion is the wrong date.
2) Sorry, I must have missed something, are you saying that essentially the MRP calcluation is through a report fired by a code unit? I'll look into this. Thanks. The only thing I have to date is that the code unit responsible is Codeunit 99000854.

@noname - Thanks, it isn't complex at all really. We have at worst 4 levels of BOM (we do have versioning). Given that we have been quoted 10 days to implement 5.0 sp1 onto 5.0 I will bloody well test this.

Thanks to you all

Idleness

Sorry, thanks for the input from you guys. I have looked at this in more detail and realised diving on here was a slight knee jerk reaction but the advice was great so no time wasted.

Anyway, we had a point in time database to test this with so before I went into the process of building replica stock levels, bom and future orders in cronus I re-ran the regen plan on this test DB (it hasn't changed at all, it was a point in time).

The regen plan was correct. So I chased our reseller. They are pinning their hats on an 5.0 sp1 upgrade based on this taken from the 5.0 sp1 release notes.....
A199) After planning the inventory level was below reorder point Error The planning engine didn't check inventory after planning. In some cases the total quantity was below the reorder point. This has been corrected

Now as you can see, this isn't our issue. I couldn't give a monkeys what the stock level is after the plan is run because we are planning regularly and anything required should be picked up within the planning dates. Couple that with the fact you guys not only understood my question but advised you haven't seen my error I am a little puzzled by our resellers thinking.

Therefore, can anyone tell me...
If the Planning worksheet regen plan is run, followed by the net change plan. Does the database get altered anywhere permanently if those suggested requisitions/actions are deleted without being actioned? Unfortunately as this was a point in time database I cannot roll it back with transaction logs.

If this looks as though I have a bee in my bonnet then that's because I have...especially when someone wants circa £20K for nowt and we get a bucket load of aggro into the bargain.

AlexWiley

That makes more sense, because that's the issue I was seeing!

Just running those plans should not post anything at all, same goes with anything that populates any journal in the system- you have the chance to review before "pulling the trigger".

Sorry for your frustration, it's an unfortunate side effect of many ERP implementations.

Idleness

Excellent, thanks Alex. I swear this was wrong, there must have been 10 people look at it and now it's suddenly correct (regen plan and net change plan). I am going to put this down as a genuine quirk for now and keep testing.

Thanks again.

David_Singleton

AlexWiley wrote:

From what I understand, "5.1" is now NAV 2009 and I was not aware it had been released yet.

No this is absolutely wrong.

5.00 SP1 is a service pack applied to version 5.00 it includes a rewrite of the planning engine and a change to sift technology, but in most other areas you should think of it as a service pack that fixes bugs and other issues with the 5.00 product.

NAV 2009 is a completely new product that is planned to be released later this year.