Due to part shortages we are trying to determine all the MRP jobs we can currently build with inventory on hand.
I have tried setting up the Production Planning Process to “Ignore Future Receipts / Requirements” (so we only go off what is in stock at the moment) as well as “Ignore Expedite PO Suggestions”. After the process runs, when I look in Production Planner Workbench under the “Jobs with Full Availability” tab I see most of the MRP jobs there, with only around 4 (or around 2%) falling under the “Shortage Jobs” tab. It is very difficult to believe with all the part shortages we have been experiencing that we currently have enough stock to build 98% of our MRP jobs.
My question is, am I correctly interpreting the meaning of the “Jobs with Full Availability” tab? Does this really mean that we could build all ~196 jobs and have parts for all of them? Or is it saying we could pick any of these 196 jobs and then after some point in the job we would have to re-run the Production Planning Process and see which of the remaining 195 jobs still have full availability after the parts from the just picked job were used up?
@Epicorus I never really got a handle on Epicor’s availability calculation, It was too optimistic for us. We recently had this need to know what jobs can I put on the floor today and I built a dashboard for operations. Attached is a generic version of it. The time phase part was from a post here already. MatStockEpicHelp.dbd (177.2 KB)
I found instructions on anther thread about making the baq file into a zip unzipping and editing the BAQVersion and the rezipping. I did that and then imported this into my 10.2.400 and exported it again.
I’m not sure how to interpret the QtyAvail field - for some jobs it is empty, for others it is a much larger number than the ProdQty, and for some it is insanely negative (the smallest number I saw was -4,354).
Have you looked into Fulfillment Workbench? It has robust search/filtering criteria to pull in a list of jobs and then automatically checks all material availability, giving % available.
Thanks, I just tried Fulfillment Workbench to verify the results. It took a while to select all MRP jobs that the BAQ are showing quantity for and it says they all can be fulfilled 100%. The only thing a bit off about this is that there are some MRP jobs that the BAQ is only saying can be partially fulfilled, although the discrepancy may be due to the fact that I have only selected MRP jobs for the Fulfillment Workbench whereas the BAQ is looking at all jobs. I’m going to try considering all jobs next and then look at only MRP, although it may take a while as it seems I can only add 100 materials at a time.
It might not be obvious, but when you ‘Refresh Fulfillment’ Epicor will try and fulfill every job from the top line down, so how you sort it matters. It will go down each line one by one, subtracting the material requirements for each line from your total on hand as it goes, so if you are showing only partial material for a given line, it might be because the material is already spoken for on a line higher up in the grid.
Ah, that could explain it then, as I’m only looking at MRP jobs and not other jobs which might also want to same materials.
Interestingly enough, while the BAQ corresponds very closely to what Fulfillment Workbench is telling me can be produced, Production Planner Workbench seems to be a bit more conservative when I run the process with “Ignore Future Receipts / Requirements” and “Ignore Expedite PO Suggestions”. This makes me think that one of these restrictions is not present in either the BAQ or Fulfillment Workbench, which may make it a bit more accurate for our purposes.
Is there a way to take this a step further and find only jobs for which we can build all jobs that rely on the parts in that job? I feel like this should be a subset of the results returned by the query, but it doesn’t seem simple as it would require that each part be able to completely satisfy all jobs that use it, not just for a single part, but for the largest set of parts that collectively go into all jobs.
Well, I may not be explaining this well. These are single level BOMs. But, for example the query gives a list of 5 different MRP jobs that can be built because sufficient parts are in stock. But for a particular part on the BOM for that Job, if we run Time Phase analysis we see that there are an addition 4 MRP jobs using that part that cannot be run because supply will be exhausted by the first 5 jobs.
We don’t want to run any of the jobs because we don’t have enough supply of all the parts to do all the jobs. But we do want to identify if there are any cases where we do have enough supply of all the parts to do all the jobs.
If it was just one part it might be easier, as we could just check that part for each MRP job returned as parts satisifed, and then see if there are any jobs using that part that can’t be satisfied. But we don’t necessarily know which parts would be the bottleneck.
So you want to move the grouping up a level to part/revision and not job. All material on all existing jobs for that part/revision without going below 0. The source is PartDtl so this should be doable. I would just make a copy and start with resetting the groupings.
