Tracking state transformation matrices define the eligibility of transformations between Tracking state codes for a given Tracking state type. This determines whether a particular tracking state entry may be added to a reference object and whether and how this affects the tracking state attributes in question. In terms of adding tracking state entries, Tracking state transformation matrices are relevant for the following mechanisms:

Choices when interactively adding tracking state entries for a reference object.
Permissibility of adding a specific tracking state entry to the Tracking state history of a reference object.
Updating the 'current Tracking state' (values of tracking state attributes) of the reference object when adding a tracking state entry to the Tracking state history.

►NOTE◄ Tracking state transformation matrices only take effect based on the mapping of the tracking state workflow for which they are configured. If no tracking state workflow is assigned in a context, then all restrictions for adding tracking states to a reference object are omitted on the one hand. However, this also means that there is no 'mapping rule' for updating the tracking state attributes of the reference object. Then, by convention, when a tracking state entry is added, only the tracking state attribute for the default Tracking state type 'Current' (CURRENT) is updated. In this case, the most recent tracking state entry of the Tracking state history is assigned as the current value. This is not necessarily the tracking state entry that was just added, as the 'External input time field' (externalInput) is taken into account instead of the creation date, if it contains a time specification.

How are 'allowed transformations' determined in the tracking history?

The mechanisms described in detail below all relate to the following procedure for determining 'valid transformations' within the Tracking state history of a reference object against the background of the tracking state transformation matrix for a particular Tracking state type:

The Tracking state history for the reference object is the result of a search for all tracking state entries related to this reference object.
The Tracking state codes of the tracking state entries found are sorted into a chronological list via the 'External input time' (externalInput) field or – if this information is missing – the 'Created date' (created) of the entry. Depending on the purpose of the evaluation (see table), the tracking state entry added will be ranked in this list or not.
Starting from a certain starting point in this chronology, the first subsequent entry is sought whose Tracking state code is a permissible successor (code) for the Tracking state code of the starting point against the background of the tracking state transformation matrix for the Tracking state type to be evaluated. A 'valid transformation' is also considered to exist if entries have to be skipped because their code in the matrix is unknown or is listed as an invalid successor.
- As long as valid successors are found, the search is usually continued cyclically with the successor as the new starting point until no more 'valid' successors are found or a termination criterion is reached.
- If no successor exists with a tracking state code that is considered a valid successor according to the matrix, the search will be aborted..

Example:

The matrix shown below specifies a simple flowchart between three Tracking state codes that can be cycled (e.g. GO! ► STOP ► HOLD ► GO! ► ...).

images/download/attachments/78252204/image2021-7-14_13-19-42-version-1-modificationdate-1627309810174-api-v2.png
In the following examples, skipped and unpassed codes are marked in red and the last code that can be accessed by valid transformations is marked in blue and underlined .

In the history HOLD ► GO! ► STOP ► HOLD ► GO! ► STOP all direct transformations are allowed, so that the sequence runs through to the end without any interruption.
In the history OLD ► GO! ► STOP ► HOLD ► STOP ► GO! the invalid second STOP is skipped. The sequence runs through to the end.
In the history HOLD ► GO! ► STOP ► HOLD ► STOP ► GO! ►GO! the sequence runs through only to the penultimate GO!
In the history HOLD ► GO! ► STOP ► BREAK ► RESET ► HOLD ► GO! the sequence runs through to the end, skipping unknown codes.
In the history HOLD ► GO! ► BREAK ► RESET ► HOLD ► GO! breaks the sequence after the first GO! because the matrix only allows STOP as the successor of GO!

Mechanisms related to tracking state transformations

The following table describes row by row the details of the named mechanisms and addresses in the second and third column differences resulting from the selection for the 'calculation mode', which can be set individually for each Tracking state transformation matrices.

Mechanism	Calculation mode 'Evaluate entire history against this matrix'	Calculation mode 'Evaluate history from current state set against this matrix'
1. Interactively selectable tracking state codes The interactive functions for adding tracking state entries to a reference object are... in the dropdown for a new entry in the Tracking state history in the context menu for the ribbon button 'Tracking state/Add' ... offered to select only those Tracking state codes that can actually be added to the reference object, depending on the applicable tracking state workflow (see Tracking state workflows).	All Tracking state codes are offered for which at least one Tracking state type provides a valid transformation for selection, starting from the actually applicable tracking state for the same Tracking state type. ►IMPORTANT◄ The selection is restricted in each case under the assumption that the tracking state entry created interactively is added as a successor to the actual actually applciable tracking state. Specifications for the 'External input' (time) in the input form for tracking state entries are not taken into account.
	The actually applicable tracking state for a Tracking state type is determined by starting from the earliest entry in the history and iteratively searching through the chronology for valid transformations for the Tracking state type (including the skipping of inappropriate entries) until the sequence is broken.	The actually applicable tracking state for a Tracking state type is determined by starting from the currently set tracking state entry in the history and iteratively searching through the chronology for valid transformations for the Tracking state type (including the skipping of inappropriate entries) until the sequence is broken.
2. When is the addition allowed considering the specified 'External input'? A tracking state entry may be added exactly, if adding it to the history at the chronological position defined by its 'External input' (time) is defined as legitimate according to at least one of the matrices of the applicable tracking state workflow. Legitimacy is evaluated individually for each Tracking state type, depending on the choice for Calculation mode (as described on the right) for the corresponding matrix. If adding the tracking state entry proves illegitimate for all tracking state types, the tracking state entry is not added, and the surrounding transaction is rolled back. Within an interactive session, an error message appears.	Adding a tracking state entry is legitimate against the background of a matrix for a given Tracking state type, if the tracking state entry to be added is EITHER attainable by a series of valid transformations (including the skipping of inappropriate entries) in a chronological search starting from the earliest entry in history without being skipped itself OR is the earliest entry in history and refers to an legitimate 'start' state.	Adding a tracking state entry is legitimate against the background of a matrix for a given Tracking state type, exactly if the tracking state entry to be added is EITHER attainable by a series of valid transformations (including the skipping of inappropriate entries) is a chronological search of the history starting from the entry set as current without being skipped itself OR if it is preceding the entry set as current and is attainable by a series of valid transformations (including the skipping of inappropriate entries) in a chronological search starting from the earliest entry in history without being skipped itself OR is the earliest entry in history and refers to an legitimate 'start' state.
	►NOTE◄ Transformations to tracking state entries dated later than the entry to be added have by definition no effect on the legitimacy of adding an entry.
3. Which tracking state entry is defined as current when an entry is added? After adding a tracking state entry, the current tracking state of the reference object is refreshed for each Tracking state type whose matrix endorsed the addition. The choice of Calculation mode for each matrix specifies logical implications as describe on the right.	The current tracking state for a Tracking state type is determined by a search starting from the earliest entry in the history and iteratively searching through the chronology for valid transformations for the Tracking state type (including the skipping of inappropriate entries) until the sequence is broken. The last tracking state entry attainable by a series of valid transformations is set as the 'current' value for the resepective Tracking state type.	The current tracking state for a Tracking state type is determined by a search starting from the currently set entry in the history and iteratively searching through the chronology for valid transformations for the Tracking state type (including the skipping of inappropriate entries) until the sequence is broken. The last tracking state entry attainable by a series of valid transformations is set as the 'current' value for the resepective Tracking state type.
	►IMPORTANT◄Adding a tracking state entry to the history may result in updates for the values of several tracking state attributes (differing in Tracking state type) of the reference object. The updated current tracking state entry is not always identical with the tracking state entry added. Besides, the Tracking state code indicated as current may appear unchanged, although a different tracking state entry with the same code is defined as current. In this respect, a high level of attention for details and sound understanding of the mechanisms described here is indispensable when configuring or testing advanced scenarios for tracking state workflows.