Oh, for sure. We just ignore those operations. We had established that top-level parts get a handful of ops to report against (FAB, WELD, BLAST, PAINT) and we don’t have them report time to every fab op in every subassembly - just the level-zero ones.
I’m missing something: it’s a part number in both cases, right? Just that one is seen and one disappears at the job level. But it would look identical* in Method Tracker, right?
*Ok, I know, technically a phantom does not have to be marked as pull-as-assembly for it to still be a phantom, but let’s just assume they are pull-as-asm for simplicity.
You are correct. I was also thinking with my configurator hat on and was talking about the top level part numbers. In the case I was talking about, we built to order and all of those configured parts were on the fly.
What I should have said is “that’s a lot of assemblies!” For our case, we didn’t want to schedule or report labor at five different assemblies since all the work was done essentially at the same time. The phantom was used for part selection and adding options - in tandem with the configurator. Pulling as assy was not adding simplicity. Having everything on a single job also simplified the pick list and job traveler.
My problem that I fought for too long was engineering BOM/paperwork mistakes. When the BOM of a job was wrong, people blamed “Epicor” and I needed to be able to trace problems back to their root cause (engineers). And I wanted some hope that other users could make that connection also. (Not so much.)
If there was a way that the material could still retain a vestige of its phantom parent, that would begin to help. But without that, I need the traceability far more than I need job traveler simplicity. I can make a custom traveler. I cannot make a time machine.
I certainly don’t disagree with what you’re trying to do. As mentioned earlier (or in another post), we needed the same and added an identifier in each JobMtl record which was (sometimes) the phantom assembly. It would be an easy BPM to populate that field. We didn’t have the Rev but in retrospect, I think I would have added it…
Not sure if it’s been mentioned in as many words up to now (long thread), but you also have to think in terms of job generation… If you have a subassembly, that means that subassembly also needs a job of its own. Sometimes it doesn’t make sense to split the jobs like this because everything is being done at the same station/machine, at the same time. So you set the subassembly phantom, and you only get one top level job with all the operations and materials…
