MRP Inconsistencies

[vobry]

I am wondering if there is anyone out there that discovers periodic , sporadic errors that result from R3482 / 3483? In general, the data is >90% accurate - it is the balance that users and the organization seem to have a problem with. Specific problems are: 1) unique key ID's do not match between the F3411/F3412/F3413 tables 2) order messages dissappear from prior Regeneration 3) Demand (in the form of a work order) does not plan (MRP message) an adequate supply in the correct planning period. All of these cases, require a 2nd regen to correct. In our initial findings the thing that comes to the surface is a limit to the # of records R3482/3483 can process. When contacting Denver for support, their solution is relying on the repost programs (R3190, R43990, and R42995) and the "Clearing the Tables" processing option. These do correct the data, but don't really adress the problem. Comments?

 

[Krofire.com]

Well, I have seen some of these problems over the years but never all at the same time. There could be any number of unrelated issues causing these problems therefore it is difficult to diagnose. However, it would be interesting to know if other users are on the system at the same time as MRP is processing? What other programs are running? What Security is set against the User running MRP? Do you spot any patterns between the times it works and the time it doesn't. Do you get any logs - what do they say? What is your database? Can you get DB logs showing record locking?

The traditional solution is to run at least one version of R3483/82 per week that clears the files. That sure helps. Users can delete messages from F3411 so that is not always a cause for concern. Do you run R3411 to auto-process messages?

This may be a dumb thing to say but I find the advice to run the Repost Programs as somewhat odd - I don't see how it would help. MRP has nothing to do with commitments because it projects Supply/Demand patterns into the future.

Another area you should check for with R3483 is the Branch Structure. R3483 processes it in the sequence you enter it in rather than the sequence you might think. You have to force in a sequence code into the "Branch Level" P3403T. Getting it wrong causes the DRP to behave differently in two runs over the same data. It looks random at first but it is just a Processing Sequencing error.

Only F3411 & F3412 have UKID and I don't think they are related. If memory serves correct they are internally maintained by R3483/2 and do not appear in F00022.

There have been a whole series fo nasty Bugs in Xe over the last couple of years but I think it should have stabilised by now. Get the highest ESU you can. I have seen obscure issues with UOM Conversion factors having too many significant figures - however, this caused the MRP to crash - it sounds like yours is finishing.

If you don't get adequate supply of F3411 Messages in the right period, then this could simply be a setup problem and not a technical one. Are you using Forecast Consumption - that can be confusing. Check your Message Fence. Order messages may well disappear after regen - this doesn't mean there is a problem unless they aren't replaced! Are you using Gross Regen or Net Change? The latter could be quirky if you aren't familiar with it. I recommend a full regen at least once a week.

I tried Parallel Processing once - it was disastrous and caused a variety of problems like you describe.

In conclusion - I can't answer the question. You may have to dissect it into different problems with different causes. There are so many variables that you may benefit from professional help onsite.

 

[vobry]

I know this was a vague description, but I appreciate your reply to the issue. It is helpful to hear other knowledgable analysis that can truly understand the operations business requirements with all of the facts about Xe to help resolve in the most suitable way. This company is the first one I have been associated with that runs MRP during the day, or during normal operations - which may be the bulk of these issues. A second no no is the use of an external PDM software to manage our revision control of the Item Master data. I am hearing that AGILE is replacing the JDE revision control programs to bring in the item data from this external software. We have had on site consultants report the data inconsistencies when this is not used standard from Xe. User Security, clearing the tables, and user education have are all in process to have the user be more self sufficient in resolving their own issues. Db logs is the next step with Denver, however the size of the log may prevent us from comunicating / finding the problems. From your responses there would be two more things I could communicate: A. We are running MRP on a nightly job scheduler. Are you aware of any processing issues through the scheduler vs a user submitted batch? B. Your comments about the "R3483 processes it in the sequence you enter it in rather than the sequence you might think. You have to force in a sequence code into the "Branch Level" P3403T. Getting it wrong causes the DRP to behave differently in two runs over the same data. It looks random at first but it is just a Processing Sequencing error." Could you elaborate on what you mean by "forcing it in to P3403T? Is this a data selection or data field that would need to be populated?

As you can tell we have our fair share of issues. I appreciate your feedback and certainly don't expect a conclusive answer to all of this. But, your right to break it into pieces and address one by one. I am hoping to stumble on some of this vision / experience of Xe and apply here where possible.

Thanks again, Mark!

 

[Krofire.com]

Aren't we in the World forum here? I launched into my chat thinking you meant OneWorld... Looks as if you are? Xe yeah? Phew.

Anyway, assuming we are talking about oneWorld:

Running during the day will cause many of the problems you experience. Spot on!

Running Agile for Doc & Revision Control should not be any kind of big deal for MRP unless the interface/Agile (this is a standard interface for Xe) is messing up BoM effectivity dates or loading Boms without correcting the Low Level Code. I don't see Agile being used to populate Leadtimes or Planning fences... But maybe they do?

Two things can effect your Scheduler Jobs versus User Jobs. Firstly the Security of the User may be different for the "User" in Scheduler. Secondly, do NOT have the Scheduler version on a Menu anywhere where a User can run them and change Data Selection at Runtime. If they do this then the Scheduler picks up the last known runtime Data Selection rather than the one you may expect.

When I used the word "force" (concerning the P3403T) I was infering that it will not default in a value. It will be blank unless you type in a number. Review the HELP on the Branch Level and it will explain how to set it up. R3483 processes highest numbers first (I believe). "Branch Level" is a data field in setup of Branch Relationships. Nothing to do with Data Selection. Do not change Data Sequence in R3483 (not that I think you would try! - If someone messed with that then get it set back to demo values.) Go to menu G3443 in demo to see the P3403T Branch Relationship Revisions. (This might help if you are using multi-site DRP with R3483 and NOT simple consolidation.) The reason it seems to process randomely is that you get different results with two runs of R3483 - in truth it is trying to blow demand up the supply chain but is starting at the top. Therefore it takes two goes to get a full explosion

 

[vobry]

Once again I thank you for this valuable feedback. Let me try and answer the questions to make this worthwhile:
A. We are in OneWorld Xe
B. We have had multiple conversations with AGILE and the adaptor software (AMX) that transfers the item data between the two. The low level code is still managed by the "On line BOM validation" constant in JDE. Effectivity Dates and Revisions are being passed with planning parameters being updated on the JDE side only.
C. We found out about the version on the scheduler "retaining" the last data selection changes about a year ago and created new versions for all batches on the shcheduler. I am currently validating any "security" differences between the scheduler and the users.
D. In regards to P3403T, we are currently in a single site planning environment (even to a lower level, but I won't get into that). From what I can tell, this program is for multi facility only and not single site: correct assumption?
E. Your words / experiences made me realize something that may be obvious to others but just "sparked the light bulb": Is the R3482 program processing records by SHORT Item #? And depending on the sequence on entering the item, R3482 would not process records in 2nd item # order, unless this is the way they were entered........ Please verify this assumption.
F. This next one I am going to ask but forgive me if I am confusing. In letter E, the assumption is the SHORT ITEM #is referenced for each record processed in R3482. Does R3482 explode the BOM requirements using the short item # or the low level code? or both? If the parent item # is in the wrong sequence of short item # in relation to the children short item #, could this be the reason for multiple R3482 batches to get the correct required quantities?

I will stop after this................

 

[Krofire.com]

No, please don't stop... Seriously, it's all good.

A: Good.
B: Oh yeah, AMX, I remember it well.
C: Good - that one nearly killed me.
D: You are running DRP over a Single Site? In which case my comments about P3403T don't apply. Although I am not sure why you are running R3483 unless you run simple consolidation over multiple branches.
E: Standard JDE MRP R3482 will process by the Business Unit (Ascending), then Low Level Code in F4102 (Ascending) and then Short Item Number (Ascending). R3483 will process by Low Level Code (Ascending), then Short Item Number (Ascending) and then Business Unit (Ascending). - That's according to the demo versions Sequencing. This shouldn't be changed.
F: If you are validating the BoM Integrity in JDEdwards (R30601) then the Low Level Codes should be correct. Errors will cause failures in BoM explosion. (Another way to screw it up would be to make mistakes in the 2nd Description of the UDC 41/I Stocking Type. If you have 'purchased' items mid-way in the BoM then the lower levels aren't exploded because it assumes you will purchase the Purchased Item - even if it has a BoM... However, I guess you would have noticed all those "Create OP" messages before now!)

However, if your LLC's are screwed-up then NO number of R3482 runs will correct the problem.. This wouldn't cause random problems.