Hi everyone! 

I wanted to share some information surrounding run numbers and MRP.  Have you ever noticed the run number between the MRP1010 and the MPPS0130 do not always correlate after an MRP run?  Well, let me give you a little information surrounding those tables and what I found. 

You might think there is an issue if you find your run numbers do not match between certain tables after running MRP run especially if you use these tables for building reports.  But rest assured it’s not an issue.  There is little to no information I could find out there so I thought I would share what I had.

 

So, what are these two tables you might ask?

 

  • MPPS0130 - This is the MRP_Setup table which shows runs that have been completed. The run number field in this table is called RUNNUMBER.
  • MRP1010 - This is the PR_Short_Items_Worktable which shows the data in the Request Resolution window for components/buy items. The run number in this table is called RNNMBR.
  • You might think that they should match.  Well in most cases they would.  Typically, there is always going to be a change each day with at least ONE of your items.  But in some rare cases, it could be possible that nothing changed with an item (quantities, transactions, order points etc) that would result in the run numbers not tying. Maybe a company holiday where MRP is scheduled to run, but no one is working so no transactions or data has been touched or something like that.

 

Findings 

    • MPPS0130 will always increment the RUNNUMBER each time MRP is run. So, you can always look here for the last number that was run. 

 

    • MRP1010 will update and correlate with MPPS0130 if there were any changes to any item(s) that are included in MRP.  All RNNMBR values in the MRP1010 for all items/records get updated if that’s the case.   

 

    • MRP1010 will not increment the run number and it will stay the same as before if there were no changes to any item(s).  The data/components itself do not change from a value perspective so that’s fine. It’s still accurate from an MRP perspective and a suggestion perspective.  

  

So, the question is, is that an issue with GP?   Short answer, no.  GP works just fine if the numbers do not correlate.  We have found no issues with how GP generates suggestions when the numbers do not tie, but it might be something you want to be aware of if you are building reports off these tables.  If you find specific situations where they don't tie when an item does change, feel free to comment below and share your findings!

Have a good one!

Warmest Regards,

Angela Ebensteiner | Sr. Technical Advisor | Microsoft Dynamics GP