Item iterations

An item is identified by its owner and the number that the owner gives to it. As the organization makes changes to the item, each change is given a new iteration.

An iteration is technical content (the revision) that's approved for a specified business purpose (the lifecycle). Each part or document record has one or more iterations.

An item iteration has its own release status, with three distinct release states: pending, released and canceled.

• A pending iteration shows that the technical content is being prepared for release. You can edit this as needed to prepare it for use. If it's not referenced by another item, you can delete it.

• A released iteration approves the technical content for its selected business purpose. You can never delete a released iteration or its iteration-level relationships; you can only create, then edit, a new pending iteration.

• A canceled iteration has been replaced or is obsolete, and cannot be used for any purpose. You cannot delete a canceled iteration or its current iteration-level relationships; you can only create, then edit, a new pending iteration.

A change form has a lifecycle that shows where it is in its approval process, but does not have revisions.

Revision (technical content) §

A revision represents a single design iteration or technical data record of a part or document.

Revision values §

Somewhat like item numbers, revision sequences define the format and rules by which new revisions are given. Unlike item numbers, a revision value isn't unique to one item; many items can have the same revision value.

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 give the next revision value in a sequence.

The business rules used to give revisions come from (1) the item's lifecycle phase, which defines the item's relative maturity, and (2) the part type's or document type's revision sequences. Revision sequence formats are specified in the Sequences: Revisions collection.

Revision sequences §

You can specify one or two revision formats in an item type, and items based on the type will follow the specification. The initial revision sequence is first used when a new item is made. 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. (This is preferred practice.)

Although no longer considered good practice, PDXpert can also switch revision sequences—say, from numeric to alphabetic—depending on the item's pre-production phase or a production lifecycle phase.

Lifecycle (business use) §

For each technical revision, an item is given a level of confidence. In early design phases, you may not have a lot of confidence simply because the item hasn't been tested and verified as useful. As the item is developed, the confidence increases. When an item is ready for full production, the manufacturing department is allowed to purchase in any quantity necessary to meet sales demands.

Lifecycle phase (or lifecycle state) §

A lifecycle phase represents one step as an item evolves from initial concept, through qualification, and on to production. 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 not even need to distinguish between preproduction and production.

A purchased screw or resistor will have a very simple lifecycle: since some other organization fully defines its characteristics, it's either qualified (released) or disqualified (canceled) for Production. 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 Field Test, 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 show pre-production states (such as design, prototype or unqualified), and values greater than zero show a post-production maturity (e.g., service only), if needed.

Normally, a production-level product shouldn't be built from pre-production parts. A parent item at production level should use child items that are also at production. You can define detailed lifecycles to ensure that, say, preliminary-level parts aren't used on beta-level assemblies.

PDXpert identifies a lifecycle mismatch between a parent and its child item on the markup list, and not on its released current list.

First pending iteration of an item §

As you make 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 correct revision sequence. That sequence's starting revision value is given to the item's revision.
• If the lifecycle phase has a non-negative relative maturity (RM ≥ 0), then the type's subsequent revision sequence determines the correct revision sequence, and that sequence's starting revision value is given to the revision. If no subsequent revision sequence has been specified, the item uses the initial revision sequence's starting value.

Later pending iterations of an item §

After the first iteration of a part record or document is released, the revision is suggested based on the lifecycle selected for the next iteration:

• If the next pending iteration's lifecycle phase has a negative RM, then the last released revision value is incremented.

• If the next pending iteration's lifecycle phase

  • has a non-negative relative maturity (RM ≥ 0), and

  • there's never been a released revision with RM ≥ 0, and

  • the Part Type or Document Type shows a Subsequent revision sequence selection.

  then the starting revision value of the revision sequence shown in the subsequent revision sequence is used.

• 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.

PDXpert expects that an item's technical content changes more frequently than its lifecycle; therefore, a new iteration automatically increments 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.

Ideally, an item's revision value and lifecycle phase selection are independent of each other. 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, NFND (not for new design). It's better to show a data change using the revision, and to show how that data is used with the lifecycle phase. For this reason (and because it's a lot easier to train for and to manage), specify only an initial revision sequence and leave the subsequent revision sequence empty.

Versions §

An item version is an optional label for data created in a different configuration management tool. This data can be copied into PDXpert, and attached to an iteration.

Versions are commonly used for computer program files to identify (a) a known set of features, (b) a set of bug fixes, and/or (c) a particular build number. For example, a version "3.2.1203" may identify the marketing feature set "3.2" plus the compiler build "1203". 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 "2.0.103" and "3.2.1203".

Versions are typically enabled for a small number of document or part types, such as a Software document or Programmed part.

Related topics

• Sequences: Revision collection
• Item Lifecycle Phases collection

1103