PDXpert PLM Software
On-line Help Guide
This help topic describes the current PDXpert PLM release. Earlier releases may be different. To view your release's version of this topic, open PDXpert and press the F1 key or select the Help menu.
Document and part iterations
Each part and document record contains approved technical content (the revision) that's intended for a specific business use (the lifecycle).
An item iteration has its own release status, with three distinct release states: pending, released and canceled. A pending iteration indicates that the current technical content is not yet approved for its intended business use. A released iteration indicates that the record may be applied as intended. A canceled iteration shows that the record may no longer be used.
You may also see the terms releasing and canceling. These are intermediate states that indicate that the iteration appears on an implementing change form's Affected item list, but the change form hasn't yet been approved and released.
PDXpert makes a minor assumption that an item's technical content changes more frequently than its lifecycle; therefore, new iterations will automatically increment the revision identifier (from, say, revision B to C) while retaining the previous lifecycle value (say, Production). This is simply a matter of convenience, and you can easily edit the revision and lifecycle values to suit your needs.
PDXpert is a product lifecycle management tool. But what does "lifecycle" mean, and why is it important to manage?
Separate from technical revisions, an item can be assigned a level of "maturity." The more expensive an item is, the more cautious you are when making major financial (e.g., inventory or marketing) commitments. When first conceived, an item may not justify any financial commitment simply because it is not yet ready for procurement — it is at the design stage. As the item is developed, the commitment becomes somewhat greater because the item is ready for prototype evaluation. Later, items are judged to be ready for full production, and the manufacturing department is given the green light to purchase in any quantity necessary to meet sales demands. In the long run, a product may become obsolete, and the inventory commitment is reduced to what is in stock, or that necessary for servicing existing products.
Lifecycle phase (or state)—
A lifecycle phase represents the maturity of an item as it evolves from initial concept, through production, and on to end-of-life (or beyond, if you have to worry about recovery and disposal). The point of identifying and managing various lifecycle phases is to control organizational behavior. If your organization's needs are simple, the business rules may only distinguish between "production" and "non-production".
A purchased screw or resistor will have a very simple lifecycle: since some other organization fully defines its characteristics, it's either Approved or perhaps later Disqualified. A more complex item, such as an automobile, will have a very sophisticated lifecycle.
A lifecycle state is most useful when it defines a unique set of business rules. For instance, you may decide that when an item is at the Prototype phase, Manufacturing can only build 10 units and Sales cannot put any into the field; if the item's phase is Beta, Manufacturing can build up to 250 units and Sales can place half of the items at selected customers' sites.
Item lifecycle phase's relative maturity—
The item lifecycle phase's relative maturity is a numeric value that can specify the lifecycle relative to a production or qualified value of zero. Negative values for relative maturity indicates a pre-production item (such as design, prototype or unqualified), and values greater than zero indicate a post-production maturity (such as service-only).
Obviously, a production-level product shouldn't be built from pre-production and obsolete parts. Therefore, you should ensure that a parent item at production level uses child items that are also at production. Likewise, pre-production items should not use or reference obsolete child items. You can define detailed lifecycles to ensure that, say, alpha-level parts don't appear on beta-level assemblies.
PDXpert identifies a lifecycle mismatch between a parent item and each child item on its markup list.
A revision represents a single design iteration or technical data record of a part or document.
Somewhat like item numbers, revision sequences define the format and rules by which new revisions are assigned. Unlike item numbers, a specific revision isn't unique to one item; many items can have the same revision value assigned.
Because multiple revisions of a part number can freely mix in the same inventory bin, best practice dictates that physical parts aren't identified by revision. When we discuss "part revisions", we're really identifying a part data record, not a physical part.
PDXpert can assign the next revision value in a sequence, and in fact can switch between revisions formats — say, from numeric to alphabetic — depending on whether the item is in a pre-production phase or a production phase.
The business rules used to control revision assignment comes from (1) the item's current lifecycle phase, which defines the item's current relative maturity, and (2) the part type's or document type's revision sequences. Revision sequence formats are defined in the Sequences: Revisions collection.
You can specify one or two revision formats in an item type, and items derived from the type will follow the specification. The initial revision sequence is first used when a new item is created. The subsequent revision sequence may also be specified, which is applied to items after they've reached a production lifecycle phase. If no subsequent revision sequence is specified, the initial revision sequence continues to be used.
First pending iteration of an item—
As you create the first pending iteration of a part record or document, you specify the iteration's lifecycle phase:
- If the lifecycle phase has a negative relative maturity (RM < 0), then the item type's initial revision sequence determines the revision sequence that's assigned, and its starting revision value is assigned to the first revision string.
- If the lifecycle phase has a non-negative relative maturity (RM ≥ 0), then the type's subsequent revision sequence determines the revision sequence, and its starting revision value is assigned to the first revision string. If no subsequent revision sequence has been specified, the item is assigned the initial revision sequence.
Later pending iterations of an item—
After you've released the first iteration of a part record or document, you can specify the lifecycle for each subsequent iteration of the item:
- If the later pending iteration's lifecycle phase has a negative RM, then the immediately-preceding released revision value is incremented using the skip characters of the revision sequence identified in the subsequent revision with RM ≥ 0.
- If the later pending iteration's lifecycle phase has a non-negative relative maturity (RM ≥ 0) and there's never been a released revision with RM ≥ 0, then the assigned revision is copied from the starting revision value of the revision sequence identified in the subsequent revision sequence.
- If the later pending iteration's lifecycle phase has a non-negative relative maturity (RM ≥ 0), then the immediately-preceding released revision value is incremented.
Ideally, an item's revision format should not reflect its lifecycle phase. An initial revision and subsequent revision can only distinguish between two lifecycle phases, while most businesses have many; some common phases are design, prototype, production, service, obsolete. It's far better to use the revision simply to indicate a change to the item's data, and allow the separate item lifecycle phase to distinguish how the data should be applied. For this reason (and because it's also a lot easier to train for and manage), we recommend that you specify only an initial revision sequence, and leave the subsequent revision sequence empty.
An item version is an optional "alias" or "label" for an iteration. While item revisions typically identify discrete steps in the evolution of an item, versions often are not sequential. Versions are commonly used for computer program files to identify (a) a specific set of features, (b) a set of bug fixes, and/or (c) a particular build number. For example, a version "3.2.203" may indicate the marketing feature set "3.2" plus the compiler build "203". While you have a very good feel for how many releases are represented in going from revision "A" to "D", you'd have little idea whether there were a few releases, or several hundred, between versions "1.0.403" and "2.1.1042". In PDXpert, a version is an attribute of its associated iteration.
Versions are typically enabled for specific document or part types, such as a Software document or Programmed part.
A reference is a part or document that's useful for creating or validating the current item. For instance, a part can refer to a list of fixtures needed for its fabrication, or a set of general-purpose documents that specify fabrication and inspection procedures, or industry standards. Similarly, a requirements document may refer to a set of industry standards that influenced its contents.
References influence how a product is processed, and therefore can't be added and removed without careful review and authorization. Just as an item must be formally released on an implementing change form, a reference must also be formally controlled on an item's list of references. Once you've added or deleted the appropriate references on the Markup list of the References tab, release the item iteration to lock those changes. The resulting approved references are shown on the Current list of the item's References tab.
Prior to an item's release, the References tab's Markup list always shows the most recent released or pending iteration for each child item. After release, the Markup tab displays the child iteration that was current when the parent was released.
An item's References tab's Current list will show various child items depending on the parent's release state. When a parent item iteration is:
- Pending: the Current list is hidden.
- Released: its Current list shows the most recent released child iteration.
- Canceled: the Current list displays the child item's iteration that was valid at the point when the parent item iteration was canceled.
Appears on ("where used")—
The set of Appears On lists show all higher-level ("parent") items where the item appears.
Help Guide Contents [PDF]
- 0001. Welcome!
- 0002. Help conventions
- 0100. PDXpert Application Server
- 0101. Server overview
- 0200. How to...
- 0300. Console reference
- 0400. How to start the PDXpert client
- 0500. Program concepts
- 0600. How to set up PDXpert
- 0700. How to use the Item Explorer
- 0800. How to use the Collection Explorer
- 0900. How to work with documents
- 0901. Manage documents
- 1000. How to start a document
- 1003. Fill in the new document
- 1004. Add a document's references
- 1005. Save your document
- 1006. Remove your document
- 1007. Release your document
- 1008. Manage a released document
- 1009. Revise a released document
- 1010. Cancel a released document
- 1100. How to work with parts
- 1101. Manage parts
- 1200. How to start a part
- 1203. Fill in the new part
- 1204. Add, modify or remove BOM parts
- 1205. Import a CAD BOM
- 1206. Add or remove approved sources
- 1207. Add a part's references
- 1208. Save your part
- 1209. Remove your part
- 1210. Release your part
- 1211. Revise a released part
- 1212. Manage a released part
- 1213. Cancel a released part
- 1300. How to revise multiple markups
- 1400. How to work with change forms
- 1401. Processing a change
- 1402. Originate a new change form
- 1403. Analyze a submitted change
- 1404. Fix change processing errors
- 1405. Remove your change form
- 1406. Review a routed change
- 1407. Resolve an on-hold change
- 1408. Analyze an accepted change
- 1409. Use a released change
- 1410. View a completed change
- 1411. Analyze a stopped change
- 1412. View a rejected change
- 1413. Remove a canceled change
- 1414. Return a submitted change
- 1500. How to work with file attachments
- 1600. How to report, import & export
- 1601. Create a report
- 1602. Export a PDX package
- 1603. Use the Report/Export Wizard
- 1700. Import & update items
- 1701. Initialize your PLM database
- 1702. Use the External Data Importer
- 1703. Item Master import
- 1704. Iteration-level relational imports
- 1705. Bill of materials import
- 1706. References import
- 1707. Revision files import
- 1708. Sources import
- 1709. Item-level relational imports
- 1710. Item files & links import
- 1711. Materials import
- 1712. Groups collection import
- 1713. Materials collection import
- 1714. Organizations collection import
- 1715. Persons collection import
- 1716. Custom collection import
- 1800. View & export via ODBC
- 1801. View database objects
- 1802. Create an ODBC connection
- 1803. ItemViews reference
- 1804. ReferencePairViews reference
- 1805. SourcePairViews reference
- 1806. SourceItemMasterView reference
- 1807. StructurePairViews reference
- 1808. ChangeViews reference
- 1809. ChangePairViews reference
- 1810. FilePairMasterView reference
- 1900. How to perform other tasks
- 2000. Menu reference
- 2100. Item Explorer reference
- 2200. Document window reference
- 2300. Part window reference
- 2400. Change Form window reference
- 2500. System Rules reference
- 2501. System Rules window
- 2502. General: Copy files to snapshot
- 2503. General: Item uniqueness definition
- 2504. General: Reviewer's comment required
- 2505. Default File Access
- 2506. Password Policy
- 2507. References Tabs
- 2508. BOM: Allow duplicate parts
- 2509. BOM: Lock part default unit of measure
- 2510. BOM: Allow partner parts
- 2600. Collections reference
- 2601. Managing collections
- 2602. Custom attributes
- 2700. Places/Organizations/Persons
- 2800. General
- 2900. Documents
- 3000. Parts
- 3100. Changes
- 3108. Custom collections
- 3200. Other reference topics
- 3300. Software licenses & legal notices