I am looking for a way to achieve the following:
I want to automatically issue all the subassemblies within my method to their parent part. Kind of like backflushing, but at subassembly level. However, I don’t want to start creating jobs specifically for these subassemblies in order to get them to Inventory so I can backflush them.
Is there a magic setting, customization, or trick that will allow me to grab these assemblies and “issue” them to the next level?
One way, is Phantom BOM. It changes the whole structure of your job, so it’s kind of a pain, and you lose visibility of those assemblies, and I’m assuming you want that visibility.
Short of that, You have to complete the last operation for the assembly to be completed and go to the next level. You can use the work queue to do some mass completions, or customize a dashboard, which is what we did.
Here’s a long thread that shows how I was able to make a dashboard in order to mass complete operations. You can tweak your dashboard BAQ and filters to get what you want, and use the start and end activity to complete the operations.
Thanks for the reply Brandon; I did see that long thread, but what I was hoping for is automatic transactions that work like backflush… It seems more and more like I have to resort to making these parts stocked in order for them to be be able to be backflushed later.
but something has to trigger the system to say it’s done right? so just complete the operations in mass instead of doing only one. You can either use a grid to have some control or run a dynamic query and just do it in the back ground.
No there isn’t an easy way to backflush assemblies. They are assuming you want to get the labor data, which takes data entry to work.
True; the completed swipe is not an issue. The problem is that the completed assembly disappears in a finished assembly area and will be physically “issued” to the parent, but never relieved from the previous state. As it is an assembly, I can’t backflush…
The sad thing is that any transaction to perform is one too many for these guys… I am currently looking at maybe re-using the “Pull Qty” as a link to a finished assembly sitting at a location waiting to be consumed by the parent. If I receive the completed part to a WIP Bin, and change the pull qty to equal the produced qty, maybe the parent assembly can backflush the finished part from that WIP bin. Probably the cold medicine talking right now…
I wouldn’t mind pulling from inventory because that’s when I could issue with a backflush. I do mind that we would have to generate jobs to build to inventory to accommodate building all these subassemblies, but I don’t see an easy way around that.
Auto Move is checked on all resource groups since we don’t use mtl handlers and queues…
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.
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.