This would work in some cases, but we would run into issues with splitting jobs between shifts between operators-- we tend to have long runs across shifts in these work centers. In that case, I think having machines with employee calendars exceptions might be the best play. The floating employees can be added instead of a machine to capability lists since they are more the exception to the rule.
On another note, when testing capabilities in Pilot, to best reset the Job Operations to utilize newly populated capabilities, would you recommend mass updating JobOpDtl to add the capability and remove required resources that were previously populated?
John, following back on Eliot’s last question… You have a method that works for updating (or deleting JobOpDtl lines? Previous setups sometimes referenced Resource groups in seq 10 and maybe a capability in seq 20. You can update job oper with the new OP and seq 10 on jobopdtl to carry the new resource group/resource/capability… buuuutttttttttttttttt… You can’t DMT delete seq 20 because the only DMT runs thru Job Oper (unless you delete the op and bring it all back.)
There’s no “update the op with the new resources” mass process like when changing an Op in job entry. And the step goes one further… updating it on methods that are stored in Eng Workbench.
I thought you could delete the JobOpDtl lines by only putting the record you want deleted in the file? I thought it would delete the JobOpDtl line and leave the JobOper record intact.
We recently upgraded to Kinetic 2024 (we are behind on upgrades.) We are trying to setup concurrent capacity on several machines so 1 operator can run 2 machines (Job A on Machine X and Job B on machine Y). The jobs are completely different with different durations, etc. We currently only have 1 scheduling block for each operation. All resources are finite. Capabilities pair an available machinist with a machine. I confirmed that the operators are in the correct capability groups to be assigned to both machines. Resource calendars are well maintained. At the resource group level, machines have concurrent capacity 1 and labor resources that we want to have run 2 machines are set to concurrent capacity 2. All the operations still have concurrent capacity 0, so I suspect I need to change that number at this point. In my situation, should the operation level concurrent capacity be set to 1 or 2? Will this need to be manually set on each impacted operation? (This field seems to default to 0 at the operation level and doesn’t change with Global Scheduling and updated resource groups. Also doesn’t change when the operation is fully reloaded or newly added.)
