Change Marks

Use

This functions allows the relevant changes to specification data to be marked on reports.

In the generation variant you can specify the following using the Change Marks indicator:

  • You can activate (value 1) or deactivate (value 0) the marking of the changes made since generation of the previous version.

  • When change marking is activated, you can also specify whether when you exchange or insert existing references, inheritance relationships, components, or transport classifications all values from the references, inheritance relationships, components, and transport classifications are marked (value 2).

Note Note

The information below is a description for references and components. All statements for references also apply for inheritance relationships, the statements for components also apply for transport classifications.

The marking of the relevant values can thus be guaranteed for transport classifications that were exchanged because of legal changes in dangerous goods.

End of the note.

Prerequisites

So that changes against previously generated reports are marked on new reports, the following prerequisites must be fulfilled:

  • The system takes into account only identifiers and value assignment instances for which a valid usage for the report exists and for which the Active indicator is set.

  • For the changed identifier or value assignment instance, you must have set the Relevant indicator, which is taken into account for the manual and automatic generation of reports (see Relevance Indicator).

  • In the header of the generation variant, you must also have set the Change Marks indicator.

  • The identifiers and value assignment instances are selected according to the selection criteria for the generation variant (rating, validity area, and possibly status check) and are examined for changes.

  • If a number of usages exist, the relevance indicator for the usage whose rating and validity area was responsible for the data selection (for example, PUBLIC) is taken.

  • The relevance indicator for the usage of an instance applies for all value assignment data and table data that is directly assigned to the instance. If an instance has changed in the interim and you have set the Relevant indicator for this instance, the following objects are marked as relevant:

    • The characteristics belonging to a value assignment instance

    • The entries belonging to a composition

Note Note

The data for composition specifications is not marked because these have their own usage with its own relevance indicator.

End of the note.

Note Note

Deleted value assignments cannot be taken into account when determining the relevance of a report because the data record can no longer be accessed and also because the corresponding usage with the Relevant indicator no longer exists.

End of the note.

Features

Determination Accurate to the Day

The system determines the change to a data record with the accuracy of one day. The determination of the relevance and the change marks are therefore also accurate to one day.

Note Note

Report bodies resulting from a relevant data change contain the Relevant indicator in the report header, which you can deselect there manually if required. In general, relevant changes lead to a new main version and nonrelevant changes to a new sub-version if versioning is activated. New main versions are automatically shipped subsequently by report shipping and report export in accordance with the legal requirements.

If the last change date of a data record is the same as or newer than the date of generation of the last report version, the system always interprets this as a change and creates a new main version or sub-version, depending on whether the change is relevant or not. In this way, no changes are overlooked, as owing to the fact that changes can be pinpointed only to one day, the system cannot decide whether the content of the data record has changed within that one day (before or after the last report generation).

End of the note.

Caution Caution

To avoid unwanted main versions being created and to avoid any unnecessary subsequent shipping, we recommend you use either automatic worklist generation or generate the report manually on the day after the change.

End of the caution.

Example Example

The following example shows versioning as determined to be accurate to one day:

  • 02/26/2003 Report generated manually: Version 1.0

  • 02/27/2003 Relevant change to a value assignment

  • 02/27/2003 New report generated manually: Version 2.0

  • 03/04/2003 Report generated manually again: Version 3.0

  • 03/04/2003 Report generated manually again: Version 3.1

  • On 02/27/2003, the report was given a new main version because the last generation date is the same as the change date. On 03/04/2003, the report was given another new main version because the system views this as the actual report generation. As no other relevant changes followed, the report was given a new sub-version in the second report generation on 03/04/2003.

End of the example.
Time-Spot Determination

You can use the environment parameter REP_TS_SUPPORT to set in Customizing that the system determines changes to data records at the exact time.

Because the system determines the times of the data change and the report generation, their sequence can also be taken into account if the actions occur on the same day.

Caution Caution

Changes that are made to a specification via inheritance relationships are only recorded by the system accurate to the day. If the Relevant indicator is set for an inheritance relationship, the exact time is not determined. Note, however, that for generation variants with Change Marks = 1, the Relevant indicator is not evaluated, and the exact time is then determined.

End of the caution.
Worklist Generation

Worklist generation also runs a text comparison in addition to the value file generation, in order to check whether a new report version is necessary. For more information, see the reference to the documentation for the report program RC1AVGE2 under Set Up Jobs for Generating Worklists in the Implementation Guide (IMG) for Product Safety.

Provided the value file generation does not detect any changes, the text comparison for all symbols checks the following:

  • Whether symbol values have changed

  • Whether additional symbols or additional symbol values were inserted in the report

  • Whether symbols or their values were deleted or are no longer printed owing to changed data or changed selection criteria for the generation variant

Note Note

The additional text comparison is not intended to detect relevant changes. This is only possible within value generation based on the usage.

The text comparison simply detects whether the new report has changed at all in comparison to the old report. Also, if a data record that is printed on the report has relevant changes, the whole report is classed as relevant.

End of the note.
Manual Report Creation

When manually creating reports, the following options are available:

  • If the last report was at least released, a new report is created.

    Here, the system must decide whether the changes to the report are relevant or not to create either a main version or a sub-version accordingly.

  • If the last report was not yet released or was historical, the last report is replaced by the manually created report.

  • In contract to worklist generation, a text comparison is not necessary in manual report creation because this does not have an effect on the relevance of a report. (Worklist generation uses the text comparison to detect whether a report has changed at all, in order to decide whether a new report must be created.)

Component Data (and Transport Classification Data) and Data from Reference Specifications

If data for components (or transport classifications) or reference specifications (or inheritance relationships) is printed on a report, when the data is output the system checks the usage and the change date of the respective identifiers and value assignment instances of these specifications.

If, for example, a value assignment instance of the component X was changed with relevant changes and a report exists for the component X, this data record appears as marked both in the report for this component and in the reports for all specifications that print the data for this component on its reports. The relevant changes also lead to a new main version that is shipped automatically using subsequent shipping if this is required by law. The same applies for changes to reference data.

Exchange of References and Components (or Transport Classifications)

If you set the value 2 for the Change Marks indicator, all values from these references (or inheritance relationships) and components are marked when you exchange or insert existing references and components.

Change Marks indicator with value 1:

If the Change Marks indicator has the value 1 and references or components are printed on the report, exchanging specifications only produces a relevant report if the corresponding data from the composition is marked as a relevant change and printed on the report.

Note Note

Changes to reference entries are always relevant because they do not have a usage. The system must therefore view an exchange as a relevant change, in order to guarantee that all relevant changes are entered.

Changes to components are either relevant or not depending on the relevance indicator for the usage of the corresponding value assignment instance.

Change Marks indicator with value 2:

  • If the Change Marks indicator has the value 2, the new reference Z (component Z) is marked even if the properties of the specification Z have not undergone any relevant changes since the last version of the report was created.

The following rules apply:

  • For the marking to work, a report with version 1.0 must already exist. The exchange of the references (components) must have taken place on the same day or after the creation of the report with version 1.0.

  • All properties of the reference Z (component Z) are marked, independent of whether they differ from the properties of the original reference Y (component Y) for an exchange.

  • The following applies for references: The relevance indicator that can be specified for a reference can also control the marking of the referenced data. Only if this indicator is set, are all properties of the reference Z also marked.

  • The following applies for components: The data of the components of a component is also marked although the components may not have been exchanged.

  • The properties of the reference Z (component Z) are only marked in the reports in which the reference Z (component Z) was newly entered as a reference (component) or exchanged. In reports in which the reference Z (component Z) occurs unchanged as a reference (component) or in reports of the specification Z itself, the properties of the reference Z are not marked.

End of the note.

Note Note

As it is possible to set a relevance indicator for references, it is transferred for the referenced data if it is set. A relevance indicator that is not set for a reference does not influence the relevance indicator of the referenced data.

In contrast, when components are exchanged and inserted, the system always assumes that changes are relevant, independent of whether the relevance indicator is set in the corresponding usage. All data that is printed on the new report as the result of the report specification having been exchanged is classed as relevant and is marked.

If one reference is replaced by another, saved, and then the same reference is entered again, the data for the reference is marked in the new report although the content of the report has not changed, whereas the relevance indicator of the reference is taken into account. (If the reference was not saved in the interim, the buffer recognizes that the specification ID has not changed and does not therefore increment the change date.)

If one component is replaced by another in a composition, saved, and then the same component is entered again, the data for the component is marked in the new report although the content of the report has not changed. (If the reference was not saved in the interim, the buffer recognizes that the specification ID has not changed and does not therefore increment the change date. If data other then the specification ID is changed in a composition, the buffer recognizes that no specification has been exchanged, despite the change to the data record, and marks only the actual changes to the composition, but not the component data that lies below the assigned component.)

End of the note.

Example Example

Sample scenario (where change marks = 2, not 0 or 1):

  • Specification X has specification Y entered as a reference specification (as a component specification). This reference is indicated as relevant. For specification X there is a report with the version 1.0, which outputs the referenced data (component data). The reference specification Y (component specification Y) is now replaced by the reference specification Z (component specification Z).

  • As the properties of the new reference specification Z (component specification Z) differ from those of the old reference specification Y (component specification Y), all value assignment instances of the newly entered reference specification Z (component specification Z) are to be marked as relevant changes in the next report version for specification X after being exchanged. The changes should be marked without a change having been made to the specification Z itself because a change to the specification Z would have an effect on the reports for specification Z. This is not desired because the content of specification Z has not changed, but it was simply used in another specification.

End of the example.