Versioning Reports 
Versioning Reports
Use
This function supports the assignment of version numbers to a number of reports that are generated for the same substance, generation variant and language.
Prerequisites
To enable versioning, you must have set the Version requirement indicator in the generation variant header.
If the relevancy indicator was set, new main or sub versions of reports are created. You can set the relevancy indicator:
The corresponding substance characteristic values are marked in the manually or automatically generated final report if you have set the Generate change marks indicator in the generation variant header, and a released and versioned report exists as a previous version. The R/3 System determines the relevant changes made since the previous report was generated.
The report may not have status RR (report request), RE (released), or HI (historical).
Features
Start version
If you generate a report for a substance, generation variant, and language for the first time and choose Accept when the report has the status CO (complete), a dialog box appears in which you specify the start number for the main version regardless of whether you have set the Version requirement indicator or not. This start version can be used as the initial report version following the replacement of legacy systems. In this case, the sub version is always zero.
Numbering
If you choose Accept again for a report with status CO (complete), the following system reactions occur:
If the Version requirement indicator |
Then |
Has not been set |
The report is always assigned the version number V1.0, regardless of whether the relevancy indicator has been set. |
Has been set, and the report is relevant |
The R/3 System assigns the next highest number to the main version and sets the sub version to zero (V2.6 ® V3.0, for instance).The R/3 System does not permit gaps in the main version. |
Has been set, and the report is not relevant |
The R/3 System assigns the next highest number to the sub version and leaves the main version unchanged (V2.6 ® V2.7, for instance). |
For reports with key date in the future that must be versioned and released before the key date is reached, you must check
If the key date is not in the future, you must create a report request manually for the key date in the future so that this report has the highest version number and no data is lost during shipping.
Version 3.2 contains substance data valid for 1st August.
Version 4.0 contains substance data valid for 1st may and relevant changes were made to it.
Version |
Generated on |
Released on |
Key date |
3.2 |
1. April |
1st April |
1st August |
Relevant change => 4.0 |
1st May |
1st May |
1st May |
If a report shipping order is created on the 1st August, the system selects the reports with the highest version numbers (version 4.0). However, the data valid for the 1st August are not contained in this version.
To create a version that contains the relevant changes as well as the data valid for the 1st August, you must create a report request manually with key date 1st August. =>
Version |
Generated on |
Released on |
Key date |
4.1 |
1st May |
1st May |
1st August |
This scenario remains the same for relevant and non-relevant changes.
Bypassing versioning
You can bypass the status CO (complete) by defining RE (released) as initial status in the generation variant.
In addition, if the Version requirement indicator |
Then |
Has not been set |
The acceptance of the report in the last release status leads automatically to the final release of the report. The report is always assigned version V1.0. During this process, the currently released report is replaced. |
Has been set |
The R/3 System automatically specifies V1.0 as the start version for the first generated report. The subsequent versions depend on whether the relevancy indicator has been set or not. |
Activities
Processing Worklists for ReportsSee also:
Generation Variant Indicator Report Management Relevance Indicator