Getting the error below for a part in MRP however the revision most def exists and is approved. For some reason it’s trying to pull a blank rev. Rev is set on the Sales Order that is also set as make direct. Anyone else ever see this before?
Is it the top level part? Or possibly used as a sub assembly, and the job that specifies it as a component, has a blank rev.
Also, is it just a coincidence that just prior to the highlighted error, the process tried to make a job with a qty equal to the Partnum in question?
This is the top level part. As far as the log goes I’m guessing that’s an issue with the logging and the label should be PartNum. I’m curious enough I may decompile and look at how they are generating that
Can you make a quick job for it? That’s my normal go to if MRP fails on a part, try making a quick job for it. Quick job normally returns a helpful error.
What’s the error on the first line of the screen shot? Is it trying to create a job in the Order-Line-Release format but it already exists?
We created a stock job to jam it through, but I still want to understand why its throwing the rev error.
In the case of the duplicate job number. If the job number for a make direct release is already existing it creates a normal MRP job with a regular ol job number vs the order-line-release number
Side bar | it’s a bug confirmed it in decompile they are using the wrong resource string. Instead of “Created new unfirm job: # Quantitiy: #” it should say “Created new unfirm job: # for Parts: #”
We get bit with dates. Engineering dates the rev effective today but the job is scheduled in the past.
Dang thought you were onto something. It’s effective date is 9/3 and MRP still fights creating a job for it.
Well a few things with dates.
First, I can’t really tell, but does your log say you are trying to make the job for Sept. 1? It’s typically the ship-by date (OrderRel.ReqDate) that governs this, or maybe the part has receive time and that is factoring in?
Second, you can get bit by alt methods, too. Not sure if you use those, but if so, check part plant for an alt method that is tied to an unapproved or future-dated rev.
Correct at this point it’s trying to make it for the first. I found out this job wasn’t getting generated weeks after it first wasn’t getting generated.
We do use them but this part does not have one, just a single rev, one operation, 2 materials, both active and ready to go.
Exactly. Rev is effective after that, on the third. So there is no approved revision as of Sept. 1.
I’m not even going to test it because you are very likely correct I see what you are saying now. Boy this is fringe. It happens to be a Rush order so the ship date was set for 9/1 and it was engineered 9/3 oy.
I wish it was fringe here. I had to create a tile for the Engineers to monitor. For us and our multi-level BOMs, it’s usually some lower-level method with a badly-dated revision.
I made a dashboard for MRP that I check every day, and have been for the last four years. How many sales order lines are “makeable” (have ANY method for the part and there is no firm job already) and how many did MRP make jobs for.