We are using phantom parts in our methods (Engineering Workbench) to group component structure. The phantom is assigned to a specific operation, and its child materials naturally inherit that operation context.
We have a requirement where a child material under the phantom has Qty > 1 but must be consumed at different operations due to process constraints.
Example scenario:
Phantom ABC is linked to Op 10
Child material: Clamp, Qty = 3
Desired consumption:
Qty 1 → Op 10
Qty 1 → Op 20
Qty 1 → Op 30
From testing, it appears Epicor does not natively support splitting a single material line’s quantity across multiple Related Operations.
Questions:
Is there any supported way to distribute consumption of a single component quantity across multiple operations when nested under a phantom?
Is the recommended pattern simply to split the material into multiple lines (Qty 1 each) and assign Related Operation per line?
Are there any downstream impacts to be aware of (MRP, backflush timing, job issue behavior) when overriding Related Operation on phantom children?
Environment: Kinetic (cloud), Engineering Workbench driven methods, significant use of phantoms.
Appreciate any best-practice guidance from those who have implemented similar structures.
What do you mean by overriding related operations?
Also, I should ask. You said phantom Materials, you also have an operation in the phantom as well, don’t you? So that the material AND the operation get’s rolled up into the parent?
Finally, is that level of detail really required in what you are doing? Most of the time it might be nice to be that exact, but it’s probably overkill to be that precise. If I have all 3 clamps available at the time of the first op that’s usually good enough. I wouldn’t get too worried about tiny details that are inconsequential, or you’ll drive yourself crazy.
Ultimately, we’re trying to get consumption right on the assembly line. These parts are set up as backflush and bin quantities can be driven negative if they don’t consume from the correct bin. Trying to avoid constantly qty adjusting bins to get the balance corrected.
Backflush and “Correct bins” are unfortunately kind of mutually exclusive. Backflush is really messy when it tries to issue, and keeping the bins accurate using epicor’s out of the box backflush logic doesn’t usually work well if it’s not incredibly simple. Like “I have one bin in the warehouse and that’s it”. If you’re trying to have multiple bins that you keep accurate level of inventory in, you’re going to have to either manually issue, or do some custom automation so that you have explicit control of how you want it to work for your specific company/situation.