With variant 2, the header is not versioned and no new object is created. Versioning with "Variant 2" is only possible if:
Versioning is performed on a child node
The versioning type on the header is set to "consistent versioning".
The header is editable
The object has already been versioned
The child is released or the release is not available.
For the direct parent node, the following applies:
If the parent node is not versioned according to Customizing or is not released, it must be editable, since a new version of the node to be versioned is created at it.
If the parent node is released, it is versioned. If the parent node is versioned consistently, it must not have already been versioned in the same object.
This applies recursively to all parent nodes of the node being versioned.
The children's children are copied unless the node to be versioned is versioned consistently. Then all children's children are moved to the successor version of the node to be versioned.
If a node is versioned under variant 2, the following applies to it:
If the child has the versioning type "weak versioning", a successor version is created. This version receives the OGUID of the object as OGUID and PREVOGUID. In addition, the validity area is set to the current time in the form of the VALIDFR.
If the versioning type is "Versioning as copy" on the child, the status of the child's successor version is also set to "Old version" (IZQAL).
If the versioning type is "versioning as copy, consistent validity area" or "consistent versioning" on the child, the validity area of the child's predecessor version is also set to the current time minus 1 second in the form of the VALIDTO.
Example 1
As an example, versioning is carried out on the child using an object. The status "Released" (IZQFR) is available in the status profile. The header and the children have the version management "consistent versioning". If the object is released, "Create version" is selected on the child via the context menu→ Change status → "Version". Variant 1 of "consistent versioning" is executed.
A new version of head A is created. The main similarities and differences between the two versions of the head can be seen in the following text and figures. The successor version of the head has the same VNR as the previous version. The version number has been increased by one. The OGUID is the GUID of the new header and the PREVOGUID is the OGUID of the old header. The validity area of the successor version in the form of the VALIDFR has been adjusted to the current time. The validity area of the predecessor version in the form of VALIDTO was set to the current time minus 1 second.
Previous version:
Follow-up version:
All children of the old object are moved to the new object. Therefore, there is neither a predecessor nor a successor version of the child. It is the same node in both objects. Accordingly, there is no change to the scope, VNR, or version number. The OGUID is the GUID of the new parent node and the PREVOGUID is the OGUID of the old parent node. The node has RELATTYP = O on both the old and the new object. The following figure shows an example of this for a node of the object.
Child B Version 1 under Head A Version 1 in ROOT A Version 1:
Child B Version 1 under Head A Version 1 in ROOT A Version 2:
Example 2
Next, child B is versioned under head A version 1.
No new version of the head is created. First, the parents of node B, and node A, are versioned. In the second step, B is versioned.
The successor version of nodes A and B have the same VNR as the previous version. The version number has been incremented by one. The PREVOGUID of the successor version is the OGUID of the first header. The OGUID of the successor version is the GUID of the new header. The validity area of the successor version in the form of the VALIDFR was adjusted to the current time. The validity area of the predecessor version in the form of VALIDTO was set to the current time minus 1 second.
Since node B is consistently versioned, the children of node B version 1 are moved to B version 2.
Node A version 1 under ROOT A version 1:
Node A Version 2 under ROOT A Version 2:
Node B Version 1 under Node A Version 1 under ROOT A Version 1:
Node B Version 2 under Node A Version 2 under ROOT A Version 2:
A collective release is made for the object. All previous versions of the nodes that have been versioned receive the status "Old version" (IZQAL) after release. The remaining nodes have the status "Released" (IZQFR).










