Hi All, I am wondering how some of you manage change for your documents. We have several soft types of WTDocument and we want them to follow a change process that is different from other WTDocument soft types and from our standard ECN process. Is it possible to configure Windchill so that a specific soft type must follow a certain change process? I'm struggling to find a solution to this problem.
I could additionally soft type the CR and CN to configure the specific workflow but there isn't anything that I know of that will restrict the object types that can be in the implementation plan. For example I don't know how to force a document "Assembly Instructions" to be changed only by the "Assembly Instructions Change Notice" object and workflow. Make sense?
Patrick Williams | Engineering Systems | c: 616.947.2110 [cid:image001.jpg@01CE637F.994E1230]
Jeff, That sounds like exactly what we need. Can you please elaborate a bit more on where in the T&M this can be configured. I don't see association constraints.
Patrick Williams | Engineering Systems | c: 616.947.2110 [cid:image002.jpg@01CE6383.AE791700]
I am asking because I get the same Parent and Child type listing for both. I would have expected to see Change Notice soft types when creating a new constraint for the Change Record.
Patrick Williams | Engineering Systems | c: 616.947.2110 [cid:image001.jpg@01CE6393.536A70B0]
Eric, Ah, I got it. Thanks very much for the explanation. Your comment about the type of ECN driving this is exactly what my initial train of thought was but I don't see a CN->CT link that I can constrain. I found a CR->Soft Type but nothing for CN.
Patrick Williams | Engineering Systems | c: 616.947.2110 [cid:image002.jpg@01CE6396.8CAE9920]
I also contemplated the approach of soft typing the CN and using ACL's to control what Team Role could create each CN soft type. However; I ran into the following problem. Within the CN/CT, a user could use the collectors to add any Affected/Resulting object to which they had access. Therefore they could inadvertently change an object through a CN/CT that was not designed for that object. It could potentially be exploited to circumvent a more rigorous change process. That is why I think I will try the relationship constraints path for a while to see where it leads. Thanks very much for your reply.
Patrick Williams | Engineering Systems | c: 616.947.2110