The QPPD offers the possibility to manage versions of objects.

Versioning in QPPD is the ability to manage different states ("versions") of an entire object or an individual node at a specific point in time.

This How-To shows the different possibilities of how versioning can be used in QPPD.

The customizing of versioning can only be explained in context and, unlike other How-Tos, does not consist of a single customizing switch that can be explained in one paragraph.

Rather, several setting options can be combined. This results in a large number of permutations, which are described below.

The How To is intended to provide a decision-making aid if it is unclear which type of versioning should be used. It shows the consequences for the data of the objects to be versioned.  Complex scenarios are illustrated with the help of many examples.

Application scenarios

For example, versioning can be used for the following business cases:

  • Parallel use of "old" and "new" data for an object.

  • Necessity of a complete history of an object in QPPD.

Principle of versioning

When an object is versioned, in simple terms a copy is created. This copy is called the successor version and is assigned the next highest version number. The object that has been versioned is also called the previous version.

Versioning can be applied to an entire object or only to a part of the entire object. In particular, it is possible to version only a single node. However, if the node to be versioned has children, these are also versioned. In the special case of consistent versioning of a child, a version of the entire object is created.

QPPD supports different types of versioning. In the following, these are referred to as versioning types.

There are five possible settings for the versioning type, which can be assigned to the specification type and/or item types.

Nr.

internal representation

Versioning type

1

' '     (blank)

Version management inactive / no versioning

2

W

Weak versioning 

3

G

Versioning as a copy

4

C

Versioning as a copy, consistent validity area

5

X

Consistent versioning

The ascending numbering is an indication of the functional diversity of the different versioning types. The highest versioning type with the most functions and the greatest complexity is "consistent versioning".

Use

In principle, every versioning type in the regulation type can be combined with almost every versioning type in the item categories. This is explained in detail in the subordinate pages to the How-To for versioning. Any exceptions are also explained here.

In principle, changes can potentially be made to various attributes of the node during versioning:

  • Status

  • Validity range (date)

  • specification number (VNR)

  • specification version (VVS)

  • Original GUID (OGUID)

  • Original GUID of the previous version (PREVOGUID)

  • Relation type (RELATTYP)

These changes can be made not only to the predecessor and successor versions of the node to be versioned but also to the parents and children of the node to be versioned. This depends on the versioning type and status of the nodes involved. The details are described in more detail in the following text.

For versioning to be performed on a node, the following conditions must be met:

  • Versioning in Customizing must be active for the node

  • The node must have the status "Released" (IZQFR) if the status is available

  • The status profile must allow the transaction "Create version" (ZQAL) for the current status

  • The node must have a specification number

  • If necessary, further conditions for other nodes of the same object

The subordinate pages deal with what has to be done to set the versioning correctly for the individual case. Furthermore, special features and possible difficulties are considered.