So we started having problems with ECO groups not being able to group check in, or group approve, or group approve and check in, when we went to 10.1. We have static ECO groups by person, not true ECO numbers. The error that shows up shows you a part number (not one that you have checked out) that is causing the error. If you that on out check out, and check back in that part number, it comes up with another one, and eventually, the error goes away. We didn’t know how many part numbers you had to check in and out before you made it through the whole list. It also messes up BPM’s that run because I’m assuming it hits that error and doesn’t say anything, but the BPM won’t fire.
Fast forward to today, the error popped up again for another user. I read the error more closely and decided to try and see in a BAQ what was going on and figured it out. What’s happening is, a part that was in the part master when it was first checked out, now is no longer in the part master (we automate a lot of part number creation and sometimes there are parts made by mistake that shouldn’t be in the system). It got removed using a different ECO group, because a different person did the fix. No I have a list of assemblies in the ECO group that don’t have part master parts to go fix.
Is there a way to fix this problem at the root so it doesn’t cause this error anymore? I would imagine that it would involve deleting these lines in the ECOMtl table, which I don’t think I can do (easily) with a BPM, or automating a check in check out process anytime a part is deleted in part master. None of which sound like they would be fun to create.
Does anyone else have any ideas? The most frustrating part of this is that it’s never related to anything that a user even has checked out. I would report it as a bug, but I’m assuming that I’ll get working as designed and I’m not ready to go through that frustration again.
Any ideas?