We have some jobs that are entered with Phantom material. then out on the floor, they remove the phantom material and pick what material they are going to use. For us, this is very specific and there is no way to do it upfront. The Phantom Material is set to 5% Scrap. In 10.1.400 when they removed the phantom and put in the exact material, the scrap did not change. Now, in 10.2.300 it does. I can not find any customization or BPM that does this,so I am a little interested now. Was this a weird function of 10.1.400 or I am wondering if the engineering got changed.
To go along with this, what issues should I look out for if we took a raw material and put it into the Engineering workbench and gave these parts a 5% Scrap without creating a separate part and linking the raw to it and the engineering it.
Is the removal of the phantom and addition of the actual done in the Job Entry? Or do you just Issue the actual part in place of the phantom, via Issue Material?
Aslo, why do you have a scrap factor? Is it to compensate for unusable fractions of the part being left over?
Like if you stock pipe by the FT, but it comes in 10 FT lengths, and a Job needs 9.5 FT. A job to make 10 would need 95 FT, and would leave 5 FT “leftover”. When actually it leaves (10) 0.5 FT pieces (which you cant use).
We are a print company and industry standard is 5% over or under. Depending
on what is order it may not always be possible to print exact quantities without higher expense. So, that is why we have it. It is done is Job Entry.
So you’re saying that changing a Mtl’s PartNum in the Job Entry, causes that Mtl’s scrap value to rest to 0?
Do the old P/N and the one it’s changed to have the same UOM (or at least a conversion between them)?
Yep, they are the exact same except for the part numbers and descriptions.
Sounds like a job for support. But if you’re really interested, you could enable trace log, and with “Track Changes Only”, and see if the Scrap Fields are being updated.
Just curious… When you change the mtl part in the Job entry, does the scrap field on the UI instantly change? Or does it display what it was, and only after saving and/or a refresh, does it show the new value?
Changes instantly. My thought is that the phantom part is what is in the part and not the specific part. So when we change from phantom to real, the scrap automatically changes because it is not in there. My logic is from that the scrap is set in the engineering workbench when crating the part. Which i think is where this conversation would ultimately lead.
the scrap is set to zero for a lot of changes. If you change the amount, scrap goes to 0 too. (it’s annoying)
I’m guessing that would be a BPM to stop that, huh? And I don’t like the idea of that as not all of our parts are 5% scrap. So, that isn’t a fix either.
If they are changing it on the shop floor, why don’t you just have them issue the material at that time? You can issue whatever part number you want. So just make placeholder part numbers for what you have on the BOM, and have them issue the right part number. You don’t need the change it on the job if you aren’t backflushing (although I do realize that different part numbers from what’s required to what is used can be challenging to see)
If you issue material to a job, is the scrap automatically added? Does it even play a part in issuing materials?
Seems like when issuing a different part, you’d want the scrap to be zero. Because your telling the job exactly how much was used.
Maybe I’m off base, but I picture it like the following: Imagine a job to make a run of printed magazines. Each Magazine requires:
- 100 YD of part PAPER. The first 10 YDs feed into the press don’t yield magazines. So s scrap qty of 10 PER JOB is added.
- 0.1 GAL of INK-BLACK. There is always 1 GAL left in the ink hopper when the job is done. This is discarded. So a scrap of 1 GAL per Job is added.
So to make 1000 magazines, 100,010 YDs of paper and 101 GAL of ink are required.
If a note comes down to substitute INK-RED for INK-BLACK, you can just issue INK-RED to the job, but you’ll issue the amount used (101), not the base qty per x job size (100).
nope. it would be more for planning purposes if you went that route. But then you get actual scrap! so you can see if there are problems. I think anything over required is considered scrap?? But I’m not sure on that.
And this is one of the problems with a % scrap solution. If you need 10 yds at the start of the run, no matter the size, then scrap going up based on the size of the run doesn’t make sense.
@Banderson @ckrusen Good points. Currently we change material in the job; hadn’t thought of doing it via issue material. That is interesting. Also, you can not forget the first couple of yd/sh/ft of material when printing. Example: We have a job that engineering requires 6.5 sheets. So we pull 7. However, we pull an additional 1-2 sheets because we didn’t hit the color right the first time, or the end results wasn’t sufficient. This is unknown until printing. Sometimes it is spot on, others it takes a sheet or 2. So we building a standard 5% to the customer and for the job to compensate. But doing it your way, via issue material at the time of use instead of in the job, would allow it to be accurate without the need for a scrap. A lot to ponder here.
I would still put the scrap on the BOM, as your purchase suggestions would have the necessary extra, but you wouldn’t have to do any many cycle count adjustments that way.
edit actually if you aren’t calling the right part number out anyways, I suppose that wouldn’t matter.
So, I talked to Tech Support and was told that it is because the Operation was set to 0% and the Material was set at 5%. So, when we remove the material and change material, it defaults to the operation %. So, I am thinking I will need to DMT the 5% into everything to get back on the right track. IS this correct or is there an easier way?
If that’s true, then that needs to be changed. The operation % is supposed to be make an extra x% widgets because they usually end up bad. Material scrap is, it takes that much extra material to make a widget. So if the material scrap rate is defaulting to the operation scrap rate, the system is double dipping. BAD.
Kinda what I was thinking, and i do not like it. But not much I can do at this time. Ideas?
DMT, or BPM’s. That’s pretty much all I got. If all or none doesn’t work, you will have to get fancy with UD fields to signify overridden scrap rates. Maybe a UD field where you hold the rate you want, and then a BPM to change the true field back to that whenever a change is made.
edit also, when you DMT, do some test to make sure that required amount changes. I know that changing the mtl cost has an update in the UI that doesn’t trigger with DMT. I think scrap works ok, but make sure you test to verify.
I would be changing it at the Bill of Operations. So only those things coming out would be affected. I am not back dating the change. Right now I am testing if it double dips or not. Do NOT want to change anything until I know that it is not double dipping.