An attempt to explain our approach:
We consider CADdocuments as the instrument for the designer. FFF does not apply to CADdocuments. Whenthe designeranalyses the version history of CADdocuments,he should be able to read the natural design evolution of a particular component or assembly.
From one revision to the next of the CADDocument, the designer is allowed to couple a new WTPart, when the design turns out not to be backward compatible (or FFF). So, there is a mapping of the design history to the article history in these links. FFF (or backward compatibility) should be applied to WTParts, not the CADdocuments.
Major/Minor is the next decision (but only when FFF applied!). A minor change is a change that not has to be trackable in the future. We don't want to know on which machines these changed parts were used. This in contrast with major changes. For major changes, we want to be able to decide where these components are used, and want to be able in the future to track where they were used.
The way we are going to implement major/minor changes in Windchill, is with view versions. When CADdocuments are raised in revision, the Design-vv of the WTPart is raised as well (in the beginning of the process). But the ERP-vv will only be raised when the change is considered as a major (at the end of the process).
In ERP, since only the ERP-vv is communicated to ERP, they will only recieve major revision on articles, and document revisions on minors and majors. This way, their information is unambiguous.
Is this somewhat clear? I have to admit, it's our concept, and our concept is not yet implemented (ERP is not ready :-). The thing is that 80% (estimated) ofour changes are minor changes, and we want to avoid by all means to confuse ERP.
<< ProE WF5 - PDMLink 10.1 M040>>