Is there a way to prevent Windchill from accepting a check-in if the list of instances in the Generic being checked in does not include all the instances that were in the latest version?
Is there a way to generate a message to the Admin when a check-in or check-in attempt of the Generic list of instances is missing instances there were in the latest version?
You are getting the same response I usually get when looking for solutions with Family Tables...crickets. Keep in mind there is a contingent out there that wants to be able to modify certain instances without touching the generic or other instances even though PTC's recommended practice is to treat the entire table as one when checking in. You would think it would be pretty easy for PTC to create a config option that hides the delete option in the menu of Creo parametric for family table rows. This is the source of the problem where the issue could be mitigated if removed.
I looked at Marco's list and it looks like the tools are there to manage the task, so I am not understanding why they aren't used.
Getting rid of Delete would help, but there are still users who type new names over existing names, which produces the same result. There is also the case where clever tykes will create an entirely different table outside of WC and import a Generic using that, stomping the existing table or just a plain item with the same name wiping it all out.
There should also be a check box to say that I don't want to revise (and release) some of the instances. Because every time I need to revise one instance, I need to revise all the instances (and related WTparts) > which in-turn gets released to ERP and confuse the planning department who think that there is some change and hence the parts are being revised and released!
No - there should not be a box that does that. It's like trying to maintain a revision of a page in a document file, such as in Word. Since there is only one file, the generic, it should be in lock-step with all the instances. Look at MIL-SPEC part drawings - there aren't separate revisions of the parts that are on those drawings; all the parts will be in accordance with the latest drawing revision, even parts that were added since the last revision.
If you need to control per-instance, create an instance level parameter called 'revision' and manage that instead and your ERP system will have something to work with.
Thanks for the reply David Schenken
@"create an instance level parameter called 'revision' and manage that instead and your ERP system will have something to work with" - Are you saying that the user will have the ability to set the revision? I am afraid the organization policy wouldn't let that happen. What benefit do we have by revising all the instance even though I want to touch (and work) only on one instance?
There are two scenarios in our environment -
1) One Drawing -> One Generic/All Instances.
2) Each Instance has a drawing.
Scenario 2 is very rare for us and represents the issue where you don't want to revise all instances at the same time. In this rare case, the family table can be converted to stand-alone. That is how we are handling it! But lucky for us it is rare. I'm guessing from your comment that you are not so lucky?
The best practice for treating the family table as one comes from many years of experience of working with them. Migration issues, marked as modified but untouched and other workspace issues...these are just some of the reasons from my 18 years of working with them.
I just wasted 20 minutes this morning with a drawing and assemlby that was missing an instance from the lower level component. The instance was removed the family in 2012!
Exactly, the second one is most common in our environment. Each instance having different WTPart and represented on different DRWs (though being on diff or same drw doesn't matter much here as I am more concerned with the WTpart - because WTparts gets pushed to SAP on revision)
I don't know of a way to do what you ask, David. I wish there was though. We regularly have a mess to clean up because someone messed with a family table who shouldn't have...
The problem with changing only -one- instance is that there is no instance. An instance is a dynamically created in-memory parametric database that depends completely on the generic file. Many alterations to instances have the opportunity to change all the instances and changing an instance requires a change to the generic. The generic file is just a program that is used to generate other programs; as such any change to the generic should be seen as a change to all the instance programs that are created using it.
I think there is no benefit in thinking or treating instances as independent (even by name they are not independent.) Because of that I see that revising all the instances along with the generic is the only action that matches how instances function, just as changing the revision of all the sheets of a spreadsheet is the only action that matches how spreadsheets function.
Since this behavior is something your organization can't handle, then I recommend using Inheritance. It makes models that can be more difficult to maintain correctly than family tables, and it's very much more difficult to audit the models that come of using it, but at least the models will be independent so they can be revised independently, except for the main parent. If the main parent model is revised then all the parts that inherit from it should also be revised.
Back to the original question - is there error detection in Windchill for preventing failed family tables into Windchill and creating failed data structures based on them? It seems like all the data required to determine that the original version of the family table had certain members and that the new version is missing some of those members without an attendent inclusion of a same-named, replacement, non-tabled item.
Is it just a matter that there is no interest in the database integrity for family table items? This seems like a function that needs to be managed. As far as I can tell the only problem anyone has with family tables is due to integrity errors. Stopping integrity errors before they are committed in Windchill seems like a worthwhile effort. Whether they are independently revisable is a preference; the problem with handling that revision is an ERP problem, one which extends far beyond family tables.