Long Running MRP

We have an issue where MRP has suddenly started to take a very long time to run. We have been running MRP once a day. The last two times MRP has run it has taken 18 and 30 hours to run. The previous runs only took 1:30. The stats on the Session log form do not show a large increase in the volume of data processed between the 1:30 running time jobs and the 18 hour plus running time jobs. The last two runs were over the weekend and the stats, apart from the run time, are identical. Are there any log files we can look at that may provide some further clues? Any ideas on why the MRP run time has suddenly shot up would be greatly appreciated.

Hi, I have noticed this kind of problem in the past. How many items and BOMs have you got? How deep are your BOMs? Please let us know. To begin with if you haven’t already done so, I would check for circularity of BOMs. Circularity errors would make the system slow. Also I would try to run consistency check against items and BOMs. Most important - could you let us know version of your Axapta please. Regards, Harish Mohanbabu

My company suffers a similar problem. We have 10 bom levels and our mrp takes in excess of 13 hours, plus firming time etc to complete. If it runs during the day it also ends up locking all the users as they try to use tables its working with, and grinds them into a very slow halt. our old mainframe took 3 hours! the wonders of modern technology.

Hi Andrew, I am not a great expert on MRP - But I know some Axapta customers running MRP without any problems - with thousands of multiple level BOMs and tens of thousands of items. As with everything else, I guess this is mostly to do with the way it has been configured. As I mentioned in my earlier reply, I will begin with checking circularity and then running consistency check against items/BOMs. Could you please try this at your end and let us know how it went. Regards, Harish Mohanbabu

Hi Harish thanks for the swift reply. we have 29 thousand items in our system, and up to 10 layers in the boms. After every mrp we run a consistency check. We sort out any errors the mrp throws out, then sort out anything from the consistency check. to actually get a result out of the consistency check we have found we can only do it on 1 module at a time, otherwise it never finishes. As we have been live 2 months now, our data integrity problems have slowly been reduced, so there are only ever a few errors on the checks. Our setup was even checked by Microsoft, they suggested a few changes. We have only ever managed to get the mrp down to 7 1/2 hours but its slowly creeping back up. The worst part is when the static plan copies over to the dynamic plan, the dynamic plan has to be deleted first (which takes ages). if any users are on during this final period and using tables it doesnt like the sql server grinds to a halt. Andrew