Thanks for the feedback, I’ll pass that along. As for the phantom there will be no operations on the phantom and the operations will be on the top level part, only the BOM as the top level operations are what can be different but the BOM always remains the same!
Hi Michael,
We have phantom BOMs with no operations. I just tested DMT in our version 10.1.600 and this works below:
Nancy
Thanks Nancy!
Mike R.
1 Like
I’ve been using DMT tool heavily and we are on 10.2.400.9, not sure if that makes any difference, but here is sample of my template:
So we have gone Live in E10 and now our Phantom BOM’s are not blowing through to the components when we create Jobs like they did (and still do) in our Pilot/Test environment. Any Ideas to help here? I did notice that in our Pilot environment. the Pull as Assembly box in the MOM is check and it is not in Live, so I changed a MOM in Live to mimic this and it did not blow through but put in in as a subassembly on the Job. I have submitted a ticket to our helpdesk but thought I would check here too.
Check the site tab on the part record. That’s the flag that actually controls it. The one on the general tab is supposed to control them, but sometimes they get out of sync.
1 Like
Thanks for the info Brandon!!
@Banderson, @MRoether - just a clarification… the fields on the front detail tab in the “Site Defaults” section are just that… DEFAULTS… for when you add a new site. In some cases, if you change the site default, a pop-up will be displayed asking IF you want the sites updated…
But in all cases, the actual value on the site tab ALWAYS wins!
below are the two screens… note that the first screenshot shows the word “Default”.
Tim, thanks for the info!!
Mike R.
1 Like
I have 2 logical questions here
- If you have intended to use part as Phantom item then why to Create MOM for that item?
- If you don’t want to create separate job for Phantom item , its okay if the operation appears because technically you will build that sub assembly while building the parent assembly why to remove operation ?
A phantom part with a method is the only reason you would have a phantom part.
If a phantom has no method, it utterly disappears when a job is created, and at that point, what on earth did you accomplish?
Question regarding Phantom parts and their BOO. If a phantom part contains a BOO, does at least one of the operations need to have a labor entry other than backflush?
We use phantom’s on what we call “exception” parts. Parts that we are only making 1 of for a special order. That phantom part will be contained within a non-phantom sub-assembly with operations of its own. We expected that the phantom BOO would blow up to the parent in a job, and ideally the BOO of the phantom could be all backflush so when the parent is transacted, the phantom part would be backflushed. From what we found, Epicor requires you to have a labor report other than backflush on at least one operation. I’m not sure if this has to do with the way the part is coded or whether we’re missing something.
One idea we had, although it’s not ideal, is to put the operations related to the phantom in the parent, but this can get messy. Any ideas on how best to capture the material and labor of a phantom part contained within a non-phantom parent?
Apologies if you know all of this, (a lot of people don’t, so it might be helpful to others if you already do)
Materials need to be related to an operation in order to be backflushed. The problem with phantom materials, if you didn’t have an operation would be that there is no way for the system to know which operation that the material would be related to when it rolls up. If you don’t have an operation on the phantom MOM, I believe the materials end up being unrelated to any operation, and will not backflush. So the only way to do that, is to have an operation in the phantom MOM that you can relate the material to. You can make these operations backflush (keep in mind that Labor backflushing and material backflushing are different things and operate differently) but I believe you have to have a later operation that isn’t backflush to trigger the labor backflush process to work.
This is true, in that you have to be able to report something somewhere to say that it’s done. But that requirement is on the job, and I don’t believe that you are forced to make that true before it gets to the job. So you can set the phantom MOM to be backflush, but if it ever ends up on job without being rolled up, it will cause a problem. So you can make the phantom operations backflush, but you have to make sure that after the job is built that you have at least one reporting operation on the assembly, and I believe that it must be after the backflush operation. I also think that the get details will pull your backflush operations before your reporting operations in the phantom BOMs, but I don’t remember that for sure, so you would have to test.
I had phantom MOM’s set up in a past life, and I know that it worked, it just confused the floor workers, as well as gave us a hard time getting job packets with the correct prints, so we abandoned the process. If you run into any specific problems as you try to get it set up, post here and I can help you work out the kinks.
2 Likes
Hello everyone, I’m in need of guidance regarding phantom BOMs. I possess a component that has both a BOM and a MOM, capable of being constructed and sold separately, as well as integrated into a larger assembly. My query is, when incorporating it into the larger parent assembly, can I allocate the operation time to the parent assembly’s operation?
Essentially, what I’m trying to understand is whether, when the component is assembled as part of a parent job and is a phantom, can I omit the operation from the specific part, since it will be constructed under the parent operation?
Not really. It will always keep that operation, even if it’s phantom. Manually adding the time and materials to the parent is really the only way you can totally get rid of it. So you’ll lose the “automatic” part of having a separate MOM, but you would gain putting the time into the singular operation. You’ll have to decide what’s more important to your business.
Alright, thank you, Brandon.
I’m considering that by back flushing the operation on the sub component, this might provide a workaround. However, this implies that it would need to be manually set as back flushed within the parent job, correct?
You can’t have a backflushed operation if you are going to have just that part though. So it’s still not automatic.
Ok thanks Brandon. I’ll keep at it, There has got to be a work around?
Not really. It’s a separate operation, or it’s not. When you have an “It depends” like you do there, how would the system know whether or not to mess with that operation or not? Other parts might not have the same situation, so without having some special flags to indicate the “depends” part, there isn’t a way to automatically manage that.
I perceive this in a rather different light. When constructed independently, it necessitates an operation. However, when integrated as a component within a larger assembly, it can be constructed utilising the operation designated for the parent assembly. In my opinion, this shouldn’t pose much difficulty and, in fact, this is often the case in many practical scenarios.