I noticed the system will assign related operation 0 or 10 depending if the parent part is a phantom. When it’s a phantom it will default to 0. When it is not a phantom adding the part will default to 10.
The system will allow you to select 0 on a non-phantom part in list view of the engineering workbench and will throw an error but it will save anyway. Then the method is broken and the system does not like it. You can also assign something on a phantom to related operation 10 when the bom has no operations (through DMT only). So I am trying to lock down any changes to the related operation. Basically if it’s phantom allow 0 or an existing operation number or if not a phantom only allow an existing operation. This was simple to do on an ecomtl data directive.
So once I thought this was figured out, an engineer added a part to a non phantom BoM and it defaulted to related operation 0. From then on it will allow us to select 0 or an existing operation.
TLDR: Besides phantom is there another reason the system would allow 0 or an existing operation?
Yes, there is one, when you want that materials are served always on the first operation, eventhough you add a new operation before the old first one, putting related operation to “0”, you force the materials to be served to the first one. That’s why phantoms are in “0”, because their material have to be served to the first operation.
Based on something one of our engineers said about his previous system I had to test this out. If you have a phantom method and assign the material to the operations like a regular method would have, you can leave out the last step like inspection or pack-out. When the phantom is brought into the higher level assembly, the method will add the phantom ops and materials first, then the parent ones. I guess some people will have a business need to operate this way. One of our companies does.
Parent:
Phantom:
Job for Parent:
I can’t vouch for whether or not it works 100% properly.
