Storing RFQs and Purchase Order Docs in Windchill

[avillanueva]

I read over Chaitanya Jagdale's J&J presentation from PTCUser. They presented their solution for compilation of a technical document for regulators. This use case is similar to a request I have regarding RFQs and POs. Currently, this involves 30-50 documents, correspondences, multiple suppliers, quotes and extracts of tech data from Engineering. 

Packages and deliveries are a definite partial solution for gathering STEP/PDF and other stuff from Engineering structures. I was wondering what is the best approach/objects to capture the other stuff. This is to be a living collection which some structure, workflow, lifecycle, going from RFQ to PO, and needs to be auditable years later.

J&J's solution used a Part object as the seed, plans, and documents to capture everything. First thought was to create a doc type and load all the content as attachments. We can links to any related Packages and deliverables, and add in all related files. Draw backs is that the files are not easily open and editable as if they were their own document.

Other approach was to treat all the files as their own document so you get the desktop integration capabilities. Structuring them to a RFQ object could be done via a Part object or a structured document. Still, it carries the overhead of having to organize the different files as objects and all that come with them. Not sure this would work to create a "template structure" of placeholders to be filled out and populated as needed. 

The Plan concept might work since it can create a templatized structure. Remember, current practices has a folder structure as buckets for content to be populated. I can see like J&J to string these concepts together with configurable links and custom tabs.  

Has anyone else gone down this road? Storing procurement data, masses of files, etc?

[MikeLockwood]

Writing out a few use cases may help really highlight the needs and help with the pros and cons of various approaches.

Seems like the use cases might include:

1. Build the collection of info, which might include New Document, Associate Document, etc. depending on the approach (somehow use templates to ensure standards and minimize steps).

2. Freeze / release the collection of info somehow, after appropriate review.

3. Modify the collection of info after freeze / release, after appropriate review.

4. All of the above for a "family" of closely-related products.

5. At some future time (5 years??) make the collection of info available to ??? for audit. Possibly this means running a report of some kind?

6. Other?

[avillanueva]

Thanks Mike, Yeah, still gathering requirements. Might try to model objects also. Its often difficult with Windchill transferring from "file" storage to "document" or "object" storage. It would be nice if Desktop Integration allowed you to interact with attachments. Still hoping someone else has charted this path with a bit less complexity that J&J.

[MikeLockwood]

I guess my suggestion on this is to try to write the use cases without using Windchill language at all (very difficult), and to do so strictly from the point of the business - what it needs, etc., treating Windchill as a black box for the moment.

This may help at least somewhat with the pros and cons of various approaches.

Your listing of needing to be auditable years from now is a great example.

This is probably not very helpful, but very interested in what you come up with.