!--a11y-->
Report
Versioning 
This function supports the assignment of version numbers to a number of reports that are generated for the same specification, generation variant, and language.
As long as a report is not yet released and not assigned a version, the new report replaces the old report. Once, however, a report has been released and therefore every version must be preserved, a new version of the report is created for the newly generated report, which does not replace the old one.
To enable versioning, you must have set the Version requirement indicator in the generation variant header.
If the
relevance
indicator was set, new main or sub-versions of reports are created. You
can set the relevance indicator:
· In the usage of value assignments and identifiers
The
corresponding data is marked in the manually or automatically generated
ready-to-ship report if you have set the
Change Marks
indicator in the generation variant header, and a released and versioned
report exists as a previous version. The SAP system determines the relevant
changes made since the previous report was generated.
Reports that contain relevant changes to specifications are included automatically when the worklist is generated.
· In the report header
The report must not have status RR (Report request), RE (Released), or HI (Historical).

The change marks are determined, regardless of whether the indicator for versioning is set. If the indicator is not set, the latest report is used in each case for the comparison and then replaced. The new report always has version 1.0, regardless of the relevance of the report.
If you generate a report for a specification, generation variant, and language for the first time and choose Accept when the report has the status CO (Completed), 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. This start version can be used, for example, as the initial report version following the replacement of legacy systems. In this case, the sub-version is always zero.
If you choose Accept again for a report with status CO (Completed), the following system reactions occur:
|
Version Requirement Indicator |
Result
|
|
The indicator is not set. |
The report is always assigned the version number V1.0, regardless of whether the relevance indicator has been set. |
|
The indicator has been set and the report is relevant. |
The SAP system assigns the next highest number to the main version and sets the sub-version to zero (V2.6 ® V3.0, for example). The system does not permit gaps in the main version numbering. |
|
The indicator has been set and the report is not relevant. |
The SAP system assigns the next highest number to the sub-version and leaves the main version unchanged (V2.6 ® V2.7, for example). |
· When main versions are assigned, no gaps in the numbering are permitted.
· A version number assigned to a report cannot be changed.
Report shipping always selects the most current released version of a report. The most up-to-date version is always assigned to the last report generated, independent of its key date.
For reports with a key date in the future that must be versioned and released before the key date is reached, you must therefore check:
· Whether a report with a higher version number was generated subsequently and released because of a change
· Whether the subsequently generated report has the same future key date
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 specification data valid for August 1.
Version 4.0 contains specification data valid for May 1 and relevant changes were made to it.
|
|
Version |
Generated On |
Released On |
Key Date |
|
|
3.2 |
April 1 |
April 1 |
August 1 |
|
|
Relevant change => 4.0 |
May 1 |
May 1 |
May 1 |
If a report shipping order is created on August 1, the system selects the reports with the highest version numbers (version 4.0). However, the data valid for August 1 is not contained in this version.
To create a version that contains the relevant changes as well as the data valid for August 1, you must create a report request manually with key date August 1. =>
|
|
Version |
Generated On |
Released On |
Key Date |
|
|
4.1 |
May 1 |
May 1 |
August 1 |
This scenario remains the same for relevant and non-relevant changes.
You can bypass the status CO (Completed) by defining RE (Released) as the initial status in the generation variant. How the system continues depends on whether the Version requirement indicator is set in the generation variant header.
|
Version Requirement Indicator |
Result |
|
The indicator is not 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. |
|
The indicator is set. |
The SAP system automatically specifies V1.0 as the start version for the first generated report. The subsequent versions depend on whether the relevance indicator has been set. |
