Mapping Service Parts to Corresponding Service Manual

[si]

Greetings all,

In an effort to improve both content and change management within our technical publications. We’d like to know if there’s a way to map service parts to any service manual referencing that particular part/s? . That is to say if a specific bolt or nut Is used across 20+ products how can we link the respect service manual to that part via PDMLink or Service Information Manager? . Which extension or native feature of Windchill allows us to do this? Can we map service instructions and parts lists to that part, so that when a change is made, that change (whether a quantity change or the obsolescence of the part)  is reflected in that service manual’s service instructions and parts lists ?

Manuals will be authored, and published via Arbortext and the Publishing Engine.

Thanks,

-Steve

[GarethOakes]

Hi Steve,

To me, this seems you are asking the same question as before, but in a different way. Content Management (Windchill Updates Reflecting in XML Content )

Mine and Jeff's answers still stand. You can link Windchill parts into Arbortext via Parts Lists, 2D Illustrations, or 3D Illustrations.

Perhaps what you are asking is can Windchill automatically raise change requests for any and all affected service data after engineering changes are made? The answer to that, is no. I think you could do this via customisation, the mechanisms that come to mind:

1. Use tagging in the authored XML data to keep lists of related parts.
2. Use Windchill "related objects" feature to link related parts on each DynamicDocument service data object.
3. As #2, above, but the other way around. Have links on each part to all related service data objects.

Once you have those relationships in place, then a process could run after a part changes and mark the relevant service data objects as possibly affected and in need of review. I don't know enough of the implementation details to advise how much effort that would take, but our company could certainly advise (www.gpsl.co).

Does that help frame the problem for you?

-Gareth

[si]

Gareth,

Regarding the first mechanism you listed; Could you explain how the tagging in the XML documents can link to service parts within Windchill? Is there a feature in Windchill that looks at the xml instance, and relates the parts contained within an xml document to parts managed within windchill?

Additionally could you explain the Windchill "related objects" feature? any documentation on these features would be greatly appreciated.

I think you could do this via customisation,

I have browsed other threads regarding customization, I'm assuming this means writing what it referred to as ACL code/script or even JavaScript correct?

Thanks for the information you've provided thus far, I'm believe the picture becoming clearer.

-Steve

[GarethOakes]

Hi Steve,

Glad this is helping.

No, there is no feature in Windchill that automates any of the process. If you wanted to tag the parts in the XML, then you would have to come up with your own way of doing that, and the "change request checker" function would have to know how to look in the XML, and what to look for. I would say in that case you would want to store the actual part IDs from Windchill in the XML. Someone would have to create that list in the first place, and also keep it updated as changes are made.

Related objects: quite a lot of Windchill objects, when you explore them, have a Related Objects tab. This is one way that Windchill has of keeping relationships between objects, conceptually this could be reused to relate service data to parts for use by the "change request checker".

Customisation means just that, tailoring the product to your needs. And yes it would involve writing code.

-Gareth