Tracking state type
The different types of tracking state are defined in the dynamic enumeration 'Tracking state type'. An individual current tracking state can be stored in a business object for each tracking state type. For further details see 'Background' (below).
By default, the system offers two tracking state types:
'Current' (CURRENT)
'Current visible' (CURRENT_VISIBLE)
These default values can be edited and localized but not deleted by the Localization or Company specific localization.
Additional tracking state types can be added to the list.
Background
The actual tracking states are not configured by means of a dynamic enumeration (see Dynamische Aufzählungen), but by means of an independent master data type Trackingstate, which does not define a reference to the tracking state type. A relationship between Tracking state and Tracking state type only arises at the transaction data level when a Tracking state entry is added to a business object:
The system first checks whether a particular Trackingstate-Workflows can be used for the respective data context and, if so, for which tracking state types transformation matrices are maintained there.
If no tracking state workflow is applicable, a tracking state entry is added without further checks and, if necessary, also mapped to the default tracking state type 'Current' (CURRENT) of the business object.
Otherwise check as described below:Each individual transformation matrix of a tracking state workflow refers to exactly one tracking state type and defines which tracking state transformations ('tracking state change') should be allowed for this type.
Based on the current tracking state of the business object for each tracking state type, the matrix is used to check whether a change to the tracking state to be added is permitted.
If checking the matrices does not result in a valid tracking state transformation for any of the tracking state types, the addition of the overall tracking state is terminated with an error message.
Otherwise, adding the tracking state becomes effective as follows:A new tracking state entry is added to the tracking state history for the business object.
For all permissible tracking state transformations, the corresponding tracking state attributes of the business object are updated or newly created.
Example
Based on the tracking states 'GO!', 'STOP' and 'PAUSE', a tracking state workflow defines the following matrices for the tracking state types 'Current' and 'Current visible':
|
Tracking state type |
to► |
GO! |
HOLD |
STOPPED |
Tracking state type |
to► |
GO! |
HOLD |
STOPPED |
|
GO! |
|
|
|
GO! |
|
|
|
||
|
HOLD |
|
|
|
HOLD |
|
|
|
||
|
STOPPED |
|
|
|
STOPPED |
|
|
|
Only the tracking state type 'Current' should therefore use the waiting state 'HOLD', while 'Currently visible' should offer a simplified status picture and only ever switch between 'GO!' and 'STOPPED'.
Based on this configuration for the tracking state workflow, the following process for a business object would be schematically possible:
|
Added |
► |
Tracking state |
Tracking state |
Comment |
|
<none> |
n/a |
n/a |
Default state |
|
|
GO! |
GO! |
GO! |
Process started |
|
|
HOLD |
HOLD |
HOLD 'current' but GO! still 'visible' |
||
|
GO! |
GO! |
Waiting state (HOLD) released again |
||
|
HOLD |
HOLD |
Waiting state (HOLD) acute again |
||
|
STOPPED |
STOPPED |
STOPPED |
Process stopped |
|
|
HOLD |
HOLD |
HOLD 'current' but STOPPED still 'visible' |
||
|
GO! |
GO! |
GO! |
Process started |
|
|
STOPPED |
STOPPED |
STOPPED |
Process stopped |
|
|
GO! |
GO! |
GO! |
Process started |
|
|
... |
... |
... |
... |