This topic is contained in the PDXpert help file, available from the application's Help menu (or press the F1 key). It describes the current PDXpert PLM release. Earlier releases may be different.
Documents convey the design, construction, service and support information of a product or process. In PDXpert, you can create a document record that is an "index card" or "container" for an electronic file, or identifies a real physical object rendered on paper or other media, such as photographic film.
When you open a new document window in PDXpert, you're not creating the actual document, but describing attributes about the document. The actual document may, however, be a file attachment, which is listed on the document record's Files tab and stored in the PDXpert file library.
These are the basic ideas for managing documents:
A document database record is identified primarily by the document's owner, type, and number. Within the document record, there are one or more document iterations. Each iteration has a technical content identifier (e.g., Revision A) and a business lifecycle phase (such as Preliminary or Production). While the document iteration is pending, you can identify references, attach computer files, and modify it however you want.
You establish reference relationships by dragging items from the Item Explorer's Search or Previous lists, and dropping them onto the Markup list of the document's References tab. References can be customer drawings, industry specifications and regulatory requirements; you can also identify physical parts such as tools and equipment used in a test or calibration procedure.
When you've finished entering information on the document record, you release the document iteration by adding it to an implementing change form's Affected tab and then approving the change form. After the change form has been approved, the document is released and the reference relationships are formalized and appear on the Current list on the References tab.
Many of the released document's attributes are locked and can never be modified;
Some attributes can be modified by members of the item trustee and product team; and
Some document attributes (such as references) can be modified only by creating a new pending iteration of the document.
You cancel a previously released document iteration by adding it to a new implementing change form's Affected tab, and approving that change form. (You don't need to remove references before canceling the document, so there is no change to the References tab.) A document iteration is canceled when (a) a replacement iteration is released, or (b) when the document is obsolete and no further iterations are desired.
To indicate a document is no longer acceptable for use, you can choose to release a new iteration with lifecycle of (say) Obsolete, or to cancel the currently-released iteration. The practical difference is whether you want the system to enforce its rules for canceled items.
Canceling the document ensures that (a) it can't be canceled unless it's also removed from all parent references; (b) after it's canceled, the document can't be added to a new Markup list; and (c) users can be prevented from opening the document through role permissions. The document can be easily reactivated by creating and releasing a new iteration, even with the same revision and lifecycle.
A new iteration of a previously-released document remains pending until you release it on an implementing change form. At that time, you'll also cancel the preceding document iteration by listing it on the same change.
At most, only one pending iteration and one released iteration can exist; any number of canceled iterations can exist.