If auto move is checked it should be pulled from where ever it is to the next operation already (what you are calling back flushed). assuming the transactions are being done in the correct order.
Something isn’t set up correctly here.
Also you can move wip, which will do what you want manually (it would be easier than having different jobs)
FWIW, we don’t really trust the WIP locations either, mostly because we don’t do the transactions in the correct order all of the time. But if it’s truly WIP it doesn’t really matter much. If it sits for a long time, then jobs to inventory might be better anyways for other reasons. WIP gets cleared when the job is closed anyways, so we just don’t worry about them.
What is it that you are seeing? Overall big picture what are you trying to do?
Actually; I am digesting the conversation you had last week on the very same topic. I noticed your use of the Pull Quantity. We have never used that, but I think it warrants review.
I know our shops are very similar to the method we build stuff. Our big picture is that we ETO complex machines consisting out of many subassemblies. Currently when our subassemblies are completed they are received into a WIP stock location. The problem is that they never get consumed from that location by their parents, even though the actual inventory does move.
I have set up a simplified demo assembly in our test system:
It might be that there is something inherently wrong in the way the system was set up or when methods were developed. I inherited an upgraded Vantage system where there was no time spent in preparing for Epicor 10…
So you are pulling them out of the job (return assembly) and putting them into inventory??? And then trying to re-issue them into the same job (issue assembly)?? Why?? Just leave them in WIP on the job. I think you’re doing too much work there. Do you have AMM? The wip locations are separate from inventory and you can see the locations. If you are doing the work to receive them to inventory, just turn off auto move, and do a wip move instead. Then when it’s used it’s “back flushed” on it’s own.
Explain turning off auto move; isn’t the only purpose of the auto move checkbox to suppress a mtl queue request for handlers, when checked?
I tried to transact as is, and my raw mtls backflushed as I completed the ops. I lost track of my finished sub assy, but Auto Move was still set on the various resource groups. Not sure where it actually ended up.
I am going to set up a new test assembly with subs and see if I can use AMM to my advantage, because it should be as simple as leaving everything on the job and use AMM as an indicator as to where stuff is while in WIP.
Well, yeah, but I’m assuming that you are returning assemblies to inventory in order to locate them right? Why else would you return the assemblies to inventory? (If that’s what you are doing). If you have auto move on, it’s a pain to move things around physically in WIP. Wip move is more about moving it from one operation to the next, not moving from one bin to another. So if you want a real location on your WIP parts, and it’s not the same every time, it’s way easier to use the material queue to do the move.
If you want to make a dashboard to move stuff around WIP, check out this thread.
Yeah, raw materials come from inventory, so you need a transaction to move them from inventory into the Job.
Are you just worried because you don’t see a transaction history on the assembly part numbers? There are no part transaction histories on the assemblies within a job. You don’t need it.
So let me get this right: when I create a dedicated Parts Coordination Operation with Auto Move not checked as the new final step for each future subassembly. Then I let the parent assembly consume it by the parts coordination guys moving it to the first operation on the parent assembly using the Move WIP function? I am not sure about how that would work. I will look at that today.
You could do that. Keep in mind, they will have to complete this operation. Depending on your business model, I think that you might be able to set operations that are generally the last up as not auto move instead of adding ops. But I guess that depends on your operations.
Also, if you have a process set up that follows the same logic every time, you can have the bins set up so that auto move puts them in the correct one.
You can also do what I did with the dashboard in the example I posted, and leave auto move on, and just change bins as you see fit.
You don’t use move wip to issue to the parent. When an operation is done, it automatically moves to the next operation, or creates a move request in your material queue. Make a job with a simple BOM, and follow the parts through the job and you can see it work. Use part tracker to see it flow through.
So for our simple job with an assembly: this contains a subassembly with three operations; upon completion of the third operation how would you get the subassembly to the parent?
It goes there automatically, when you look in part tracker, it will show you the assembly and operation that the part it on. That assembly sequence is not the one that the part is, it’s the parent one.
I can check all of this when I get a chance, but I’m 90% sure that’s the way it works. If it’s not there, then open up your material queue you should have a move request.
I could be wrong, because we have auto move on everything.
So I’m working on an example for this. Here’s what seeing. (I have auto move on for this test)
Here’s my job structure. I just complete op 10 and op 20.
When I look in part tracker for this part to say where it is. It is at “paint” which is OP 30 (I haven’t started that yet). So the parts, when they are done from one op to the next move to the next operation. All of our wip just sits in bin 1, so that’s the bin location set up for auto move in the resource group.
Now here are some gotchas with AMM that make this system sort of useless in the real world.
I didn’t do any of the operations for the other assemblies, as you can see,
So if I go and complete these operations.
The part never shows up in WIP. This actually surprised me a little bit, as I though without negatives being allowed, I thought it would show up. But it didn’t, so it’s been “backflushed”
This is awesome what you are doing and really helps. We are going to go back to basics with our Methods tomorrow. I think we might have over-complicated things in the past…
so now with auto-move turned off. I will do the same things. I completed op 10 and 20.
Part tracker now shows the parts at the next operation. I was thinking with auto move turned off, it wouldn’t be that way, but it does. It looks like it’s working the same way with auto move turned off. (Which is interesting ) I’m wondering if I need to do something else here.
So there’s more stuff that can be looked at with the material queue and moving things, but before I spend any time on that, what is your ultimate goal with visibility? Do you need everything in a bin location that needs to be set between each op? Is setting up default bins good enough? If it’s truly moving WIP it probably should be. If it’s sitting a long time, you could think about whether it should be jobs into inventory or not.
So what your ultimate goal is will shape which tools you are using.
Brandon; thanks again for the terrific notes. It turns out that we are over complicating things, and I am planning to revert back to using Epicor as intended. What is driving the over complication was the need to put a location on an assembly as it was completed. The heart of the issue is a procedure problem where we don’t adequately define what we do with our finished assemblies. Now we have gotten to the bottom it is easier to implement change…
) I’m wondering if I need to do something else here.