Material Yield vs Scrap in MRP Calculations

Epicor ERP 10
, ,
1

My company struggles with raw material procurement & inventory. Epicor appears to be working as designed. Demand for 100, with inventory of 40, results in buy suggestion of 60.

However, …

Those who have raised their hands in sympathy & support, can put them down now. I appreciate it.

We raise jobs for production batches of parts that consume standard sized raw materials, some of which becomes parts, some of which becomes chips & remnant.

The remnant can be put back into inventory but a square foot of raw material is not the same as (144) (1) inch by (1) inch Chiclets, so we do not put them back into inventory under the original part record number, which would artificially inflate the “useable” inventory qty.

A percentage of the raw material ends up as chips, rather than remnant.

You might also call the chips scrap material, but we do not go through the tedium of DMRing or inventory transacting the quantity of scrap out of the job.

On top of this, a number of standard, let’s say sheets of material, are used up in a process that may make a number of different part batches at the same time.

The scenario in question is an NC router, onto which a number of standard sized sheets are stacked, and from which a number of nested parts are cut. We encounter a huge mix of part numbers at very small production rates, so no nest is ever the same, or predictable.

We use the material for the hottest part as the determining factor for each nest material stack, and the nest is then filled with parts that use the same material.

The nesting software does provide data that defines what percentage of the stacked sheets becomes parts, & by simple calculation what percentage is chips.

What we would like to do is data mine Epicor &/or the Nesting software to establish an average percentage part yield, or what the nesting software calls “actual efficiency” for every material.

That is, if you’re NC routing a standard sized sheet, on average, some percentage will actually become parts, and use that average data-based efficiency to influence MRP calculations for buy suggestions.

For example:
Our methods planners develop MOMs for production parts, & enter raw material quantities based on the minimum sized rectangle of raw material required to make one part. How the part will be nested, & what parts will be nested with it, is unknowable. What the material yield efficiency of any one nest is also unknowable, ahead of time anyways. So no attempt for compensation is made at the MOM level.

MRP uses this MOM BOM entry to calculate an inventory UOM demand for the material, looks at what is in inventory, & makes a buy suggestion that is never right, because Epicor is unaware of material process yield efficiency. It can’t be, unless you tell it.

Here’s a real data-based example from one of our nests:
The actual yield efficiency of the material in the nest is 67% parts, 33% chips & unusable chunks.

Epicor demands 100 sft of sheet stock, based on MOM qty, based on min rectangle size to make one part.
Inventory is 40 sft.
Buy suggestion is 60 sft.

But at 67% yield efficiency:
40 sft of sheet stock will only yield 26.8 sft of parts.
60 sft of sheet stock will only yield 40.2 sft of parts.
For a total of 67 sft of parts, & we need 100 sft of parts.
@ 67% material yield, we need over 149.25 sft of material to make 100 sft of parts, & 40 sft of inventory only makes 26.8 sft, so the buy suggestion should be 122.2 sft of sheet stock, over twice what Epicor, which is ignorant of the material yield, suggests.

Armed with our data mined average material efficiency we would like to correct the Epicor MRP calculations by coming up with a multiplication factor that deflates the inventory values & inflates the demand before the inventory is subtracted from demand, so that the buy suggestion is more accurate.

Customization is the obvious thing that comes to mind, but I would like to keep the customizations to a minimum & avoid unpredictable entanglements with Epicor business logic, by perhaps using existing Epicor data fields to influence MRP.

I’m thinking that a material efficiency number would have to be stored in the part record, regardless of how, or what data we use to create it, so it could be referenced by MRP calculations to inflate demand & deflate inventory values.

I’m looking at the scrap rate percentage under the MOM Materials Detail tab as a way to inflate material demand, but I’ve read conflicting opinions on how it works. The MRP reference manual & application field help don’t give me much confidence or help.

I’m not sure how or what fields might exist to deflate the value of inventory in MRP calculations.

Let the debates begin …

2

The following comes from my perspective in metal stamping, laser cutting (of metal sheet), and CNC cutting (mills, lathes, 5-axis):

If you are able to get your average material efficiency from your nesting software, then I would use this to increase the BOM’s Quantity per Parent for the material. For example, if one finished part is physically one sqft of material but your efficiency is only 67%, then enter the material’s quantity per parent on the BOM as 1 / 0.67 = 1.49253. This will cause MRP to “need” the inflated amount of material, no customizations required.

As an example: we buy 48" x 120" (=20 sqft) sheets of steel to cut on our laser. A particular part may physically only be made up of 0.5 sqft of steel. However, given historical averages, we are only yielding 20 parts from this sheet instead of the theoretical 40. Instead of entering 1/40 = 0.025 sqft of material per part in the BOM, we enter 1/20 = 0.05 sqft to reflect the fact that we are “losing” half of the sheet to cut-off that may or may not be reclaimed as different material part numbers. If we have a job for 100 parts, MRP will recognize that we need to use 5 full sheets of steel to account for the yield we get.

I don’t believe you need to do any customization to have MRP drive demand as you would like. This would be handled by the standard quantity per parent calculations in the bill of materials.

As for deflating inventory value, would this be deflating the value of the finished part? If you are normally never able to use the chips or chunks produced by these nesting inefficiencies, then the cost of that extra material should be included in the cost of the final part. If those chips or chunks can later be used, Epicor lets you define a Salvage part and quantity for materials: this is material you salvage from a job to use later under a different part number, and this will also reduce the material cost applied to the finished part.

1 Like
3

Thanks Tyler,

Yes, that is absolutely one way to do it. And it is still under consideration for us. Our issue is the logistics of updating literally thousands of BOMs, for thousands of parts, & even more thousands of materials. It would be a brute force effort.

It’s not a hard requirement, but we would like to have the material qty represent the part size, as closely as possible.

The other issue is timing. When first creating a MOM for a new part, our methods planners are certainly aware of the actual part size, but if the material is new, wouldn’t have any historical nest data to base a yield efficiency factor on. The answer to that I suppose would be using a factor from a like material, & updating later, when we have nest data. A manual process, that can be overlooked, forgotten, or just ignored, until someone complains about it.

The more I think about this, the more I’m thinking we are going to have to customize something. The question is what. And if we’re going the customization route, can we automate it & set it up to tune itself over time, so that it adapts to shop load & any changes in part or material mix.

Our first step, before any customizing occurs, is to set up an Epicor database to dump nest data into, & then develop a material efficiency factor from that data, for each material. We might develop an Epicor process that runs through the data as it accumulates, to calculate an updated efficiency at regular intervals, which may give us a tuning feature over time.

Our second step might be to update a user defined material efficiency field in the part record of every material.

Our third would be to customize the MRP process to use the efficiency factor in its calculations, making the whole thing automatic start to finish,

I know I said we wanted to avoid customization as much as possible, & that still holds. But we also don’t want to compromise the desired functionality, just to avoid it.

And so, we look around, and ask the question, “Does Epicor have a way to do something without customization?” “Does it have a hidden feature, or function, that will get the job done?” “If we’re diving into customization, what’s the best thing to customize, that is least likely to break in the future?”

4

Wouldn’t you consume slightly less raw material inventory over time (since you’re nesting ‘free’ jobs in with the main job), and if you’ve got min qty set on those raw materials, the buyers will only buy the amount necessary.

But if you wanted to calculate it, you could sum up the raw material needed (get area from weight might be quicker than taking it from the CAD software for every part) divided by the raw material used (STK-JOB inventory transactions in PartTran).

5

There’s no main job, or free jobs.

Our standard sheet size is 48" x 144", & we stack the sheets up to 6 high, or a max total thickness of .250"

We make a very high mix of part numbers, in small production batch sizes of around (6).

We determine the NC router Nest Material by picking the highest priority job (that needs routing) in our Detail FAB shop, This nest material defining job will typically use up a very small percentage of the Nest material, the balance of the Nest is filled out with parts made of the same material, in Detail FAB shop priority order. There may be dozens of part numbers cut together in one nest. Again, high mix, low rates. It’s the nature of our business. Our ERP system is integrated with the nesting software to split the material cost up based on part size. No free parts or jobs.

Once a nest is cut the next nest material is again determined by the highest priority job in the Detail FAB shop (that hasn’t been routed yet), & the process repeats. The priority of the parts gets jumbled by this batching process, but each nest contains the “hottest” unrouted part, plus parts made of the same material, to fill out the nest.

What we find is that the part size only based estimates of material needed is always less than what gets consumed, because no nest is the same or predictable.

To provide some context, our Detail FAB shop is nothing like a production line. It’s a giant job shop. Each job snakes its way through the work centers in the shop in an order that is unique to the part. The NC router is just one of them. And the NC router is shared by a large number of part numbers, in relatively small production batches. There are no economies of scale. It’s all about flexibility.

We machine rod, bar, & plate, with NC machines. We machine extrusions & sheet metal shapes with NC machines specialized for that. We rout flat pattern sheet metal parts with an NC router.

Everything goes through a deburring center.

Machined parts are inspected & may or may not be sent off to chem-processing, the paint shop, part mark, & final inspection.

Extruded parts may require joggling before chem-processing, the paint shop, part mark, & final inspection.

Sheet metal parts often require solution heat treat before hydro or brake forming, hand-work, age hardening, & then chem-processing, the paint shop, part mark, & final inspection.

I guess my point is that our NC router is just one stop along the path that a part may take through the Detail FAB shop. It will be one operation in a Method of Manufacture that contains a dozen or more operations that each represent a work center of some kind. As a result, there is no constant direct supervision &/or modification of a part’s MOM. We set a MOM up like a recipe, & may run it once a week, once a month, or once a year. And the MOMs & work centers are flexible enough that the MOM results in a good part, if not the most efficiently made part.

Which is why I’m looking for a way to data mine Epicor & our machining software to establish an average material-based part yield efficiency factor I can implement to make our MRP material buy suggestions more accurate, rather than perfect.

And then figure out a way to implement that factor into Epicor.