I’m not sure if this is fixable and we can work around but just in case…
We have complex multi-level bill of materials with nested sub assemblies. We create a single job for a saleable part made up of all of the sub -assemblies and the sub assemblies are set to pull as assembly and view as assembly.
Our first operation on each sub assembly is typically an operation to cut the sub assembly from a sheet of steel. As these sub assemblies are typically cut from the same grade and thickness of steel we physically nest different sub assemblies in the same sheet and they are worked on together. We cannot use batch jobs for these operations as the complexity of our boms causes it to break.
To assist the operators who are running this operation for these jobs and to prevent them having to go into start production| end activity for each assembly on the part we are trying to use the current work queue to let select and bulk start assemblies.
We thought as the cutting operation is the first operation on each sub assembly that they would all be listed in current work once the job is released. We are finding that any sub assembly that itself has a sub assembly is not appearing in the current work queue, rather it is appearing in the expected work queue. It seems that it will not appear in the current work queue until all operations, not just the cutting operations, on the child sub assembly has been fully completed.
To try and put it simply, at the cutting op, every assembly is available to cut, no matter the status of it’s parent, it is only in subsequent operations, where for example the child assembly is welded onto the parent assembly that the parent and child relationship becomes significant to the sequence of actual/expected work.
The cutting operation uses raw material parts that are only used on that operation.
Is there any way of manipulating the BOM/Route to have every single assembly on a BOM available to work at the first op as current work without breaking the rest of the parent/child relationship.
As I said we do have a work around, where the operator checks the expected work queue as well as current work - that queue does seem to handle all the different levels.
I hope that this makes sense.