Trackingstatus-Transformationsmatrizen definieren die Zulässigkeit von Übergängen zwischen Trackingstatus-Codes für einen bestimmten Trackingstatustyp.

Siehe auch: Arbeiten mit Trackingstatus, Trackingstatus-Workflows, Trackingstatus-Transformationsmatrizen, Trackingstatus

Trackingstatus-Transformationsmatrizen definieren die Zulässigkeit von Übergängen zwischen Trackingstatus-Codes für einen bestimmten Trackingstatustyp. Davon hängt ab, ob ein bestimmter Trackingstatus-Eintrag einem Bezugsobjekt hinzugefügt werden darf und ob und wie sich das auf die betreffenden Trackingstatus-Attribute auswirkt. In Bezug auf das Hinzufügen von Trackingstatus-Einträgen sind Trackingstatus-Transformationsmatrizen für folgende Mechanismen relevant:

Auswahlmöglichkeiten beim interaktiven Hinzufügen von Trackingstatus-Einträgen für ein Bezugsobjekt
Zulässigkeit des Hinzufügens eines konkreten Trackingstatus-Eintrags zur Trackingstatus-Historie eines Bezugsobjekts.
Aktualisierung der "aktuellen Trackingstatus" (Werte von Trackingstatus-Attributen) des Bezugsobjekts beim Hinzufügen eines Trackingstatus-Eintrags zur Trackingstatus-Historie.

►HINWEIS◄ Trackingstatus-Transformationsmatrizen greifen nur auf der Grundlage der Zuordnung des Trackingstatus-Workflows, für den sie konfiguriert sind. Ist in einem Kontext kein Trackingstatus-Workflow zugeordnet, dann entfallen einerseits alle Restriktionen für das Hinzufügen von Trackingstatus zu einem Bezugsobjekt. Andererseits fehlt damit auch eine "Abbildungsvorschrift" für die Aktualisierung der Trackingstatus-Attribute des Bezugsobjekts. Per Konvention wird dann beim Hinzufügen eines Trackingstatus-Eintrags per Konvention nur das Trackingstatus-Attribut für den Standard-Trackingstatustyp "Aktuell" (CURRENT) aktualisiert. Als aktueller Wert wird dabei der "jüngste" Trackingstatus-Eintrag der Trackingstatus-Historie zugewiesen. Dabei handelt es sich nicht unbedingt um den gerade hinzugefügten Trackingstatus-Eintrag, da das Feld "Externe Erfassungszeit" (externalInput) anstelle des Erstelldatums berücksichtigt wird, sofern es eine Zeitangabe enthält.

Wie werden "zulässige Übergänge" in der Tracking-Historie ermittelt?

Die unten im Detail beschriebenen Mechanismen beziehen sich alle auf das folgende Verfahren zum Ermitteln von "zulässigen Übergängen" innerhalb der Trackingstatus-Historie eines Bezugsobjekts vor dem Hintergrund der Trackingstatus-Transformationsmatrix für einen bestimmten Trackingstatustyp:

Die Trackingstatus-Historie für das Bezugsobjekt ist das Ergebnis einer Suche nach allen Trackingstatus-Einträgen, die sich auf dieses Bezugsobjekt beziehen.
Die Trackingstatus-Codes der gefundenen Trackingstatus-Einträge wird über das Feld "Externe Eingabezeit" (externalInput) oder - falls diese Angabe fehlt - das "Erstelldatum" (created) des Eintrags in eine chronologische Liste einsortiert. Abhängig vom Zweck der Auswertung (s. Tabelle) wird der hinzuzufügende Trackingstatus-Eintrag in diese Liste eingereiht oder nicht.
Ausgehend von einem bestimmten Ausgangspunkt in dieser Chronologie wird nach dem ersten nachfolgenden Eintrag gesucht, dessen Trackingstatus-Code vor dem Hintergrund der Trackingstatus-Transformationsmatrix für den auszuwertenden Trackingstatustyp ein zulässiger Nachfolger(-Code) für den Trackingstatus-Code des Ausgangspunkt ist. Ein "zulässiger Übergang" gilt dabei auch als gegeben, wenn dabei Einträge übersprungen werden müssen, weil deren Code in der Matrix unbekannt oder als unzulässiger Nachfolger geführt ist.
- Solange zulässige Nachfolger gefunden werden, wird die Suche in der Regel mit dem Nachfolger als neuem Ausgangspunkt zyklisch fortgesetzt, bis kein "zulässiger" Nachfolger mehr gefunden oder ein Abbruchkriterium erreicht wird.
- Existiert kein Nachfolger mit einem Trackingstatus-Code, der laut der Matrix als zulässiger Nachfolger gilt, wird die Suche abgebrochen.

Beispiel:

Die unten abgebildete Matrix spezifiziert ein einfaches Ablaufschema zwischen drei Trackingstatus-Codes, das zyklisch durchlaufen werden kann (z. B. GO! ► STOP ► HOLD ► GO! ► ...).

images/download/attachments/78252204/image2021-7-14_13-19-42-version-1-modificationdate-1627309810174-api-v2.png
In den folgenden Beispielen werden übersprungene und nicht durchlaufene Codes rot und der letzte durch zulässige Übergänge erreichbare Code blau und unterstrichen gekennzeichnet.

In der Historie HOLD ► GO! ► STOP ► HOLD ► GO! ► STOP sind alle direkten Übergänge zulässig, so dass die Kette lückenlos bis zum Ende durchlaufen wird.
In der Historie HOLD ► GO! ► STOP ► HOLD ► STOP ► GO! wird das unzulässige zweite STOP übersprungen. Die Kette läuft bis zum Ende durch.
In der Historie HOLD ► GO! ► STOP ► HOLD ► STOP ► GO! ►GO! läuft die Kette nur bis zum vorletzten GO! durch.
In der Historie HOLD ► GO! ► STOP ► BREAK ► RESET ► HOLD ► GO! läuft die Kette bis zum Ende durch, wobei unbekannte Codes übersprungen werden.
In der Historie HOLD ► GO! ► BREAK ► RESET ► HOLD ► GO! bricht die Kette schon nach dem ersten GO! ab, weil die Matrix nur STOP als Nachfolger von GO! zulässt.

Mechanismen mit Bezug zu Trackingstatus-Übergängen

Die folgende Tabelle beschreibt zeilenweise die Details zu den genannten Mechanismen und geht in der zweiten und dritten Spalte auf Unterschiede ein, die sich aus der Auswahl für den "Berechnungsmodus" ergeben, der jeder Trackingstatus-Transformationsmatrizen individuell festgelegt werden kann.

Mechanismus	Berechnungsmodus "Gesamte Historie gegen diese Matrix auswerten"	Berechnungsmodus "Historie ab dem aktuell gesetzten Status gegen diese Matrix auswerten"
1. Interaktiv auswählbare Trackingstatus-Codes Die interaktiven Funktionen zum Hinzufügen von Trackingstatus-Einträgen zu einem Bezugsobjekt sollen ... im Dropdown für einen neuen Eintrag in der Trackingstatus-Historie im Kontextmenü für den Ribbon-Button "Trackingstatus / Hinzufügen" ... jeweils nur die Trackingstatus-Codes zur Auswahl anbieten, die dem Bezugsobjekt abhängig vom jeweils anwendbaren Trackingstatus-Workflow (s. Trackingstatus-Workflows) dann auch wirklich hinzugefügt werden können.	Es werden alle Trackingstatus-Codes zur Auswahl angeboten, für die mindestens ein Trackingstatustyp einen zulässigen Übergang ausgehend vom eigentlich aktuellen Trackingstatus für denselben Trackingstatustyp vorsieht. ►WICHTIG◄ Die Auswahl wird jeweils unter der Annahme eingeschränkt, dass der interaktiv hinzuzufügende Trackingstatus-Eintrag als Nachfolger des eigentlich aktuellen Trackingstatus hinzugefügt werden soll. Angaben für die "Externe Eingabezeit" in der Erfassungsmaske für Trackingstatus-Einträge werden nicht berücksichtigt.
	Der eigentlich aktuelle Trackingstatus für einen Trackingstatustyp wird ermittelt, indem ausgehend vom frühesten Eintrag in der Historie entlang der Chronologie iterativ nach für den Trackingstatustyp zulässigen Übergängen (inkl. Überspringen von unpassenden Einträgen) gesucht wird, bis die Kette abreißt.	Der eigentlich aktuelle Trackingstatus für einen Trackingstatustyp wird ermittelt, indem ausgehend vom derzeit aktuell gesetzten Trackingstatus-Eintrag in der Historie entlang der Chronologie iterativ nach für den Trackingstatustyp zulässigen Übergängen (inkl. Überspringen von unpassenden Einträgen) gesucht wird, bis die Kette abreißt.
2. Wann ist das Hinzufügen unter Berücksichtigung der angegebenen "Externen Eingabezeit" zulässig? Ein Trackingstatus-Eintrag kann genau hinzugefügt werden, wenn das Hinzufügen zur Historie an der durch die "Externe Eingabezeit" definierten chronologischen Reihenfolgeposition durch mindestens eine der Matrizen des anwendbaren Trackingstatus-Workflows als zulässig bewertet wird. Für jeden Trackingstatustyp wird die Zulässigkeit - wie rechts beschrieben abhängig vom Berechnungsmodus für die jeweilige Matrix - individuell bewertet. Gilt das Hinzufügen für keinen Trackingstatustyp zulässig, für den eine Matrix hinterlegt ist, wird der Trackingstatus-Eintrag nicht hinzugefügt, sondern die betreffende Transaktion zurückgerollt. In einer interaktiven Sitzung erscheint eine Fehlermeldung.	Das Hinzufügen ist vor dem Hintergrund der Matrix für einen bestimmten Trackingstatustyp genau dann zulässig, wenn der hinzuzufügende Trackingstatus-Eintrag ENTWEDER ausgehend vom frühesten Eintrag in der Historie entlang der Chronologie über zulässige Übergänge (inkl. Überspringen von unpassenden Einträgen) erreicht wird, ohne selbst übersprungen zu werden ODER wenn er selbst der früheste Eintrag der Historie und als Start-Status zulässig ist.	Das Hinzufügen ist vor dem Hintergrund der Matrix für einen bestimmten Trackingstatustyp genau dann zulässig, wenn der hinzuzufügende Trackingstatus-Eintrag ENTWEDER ausgehend vom derzeit aktuell gesetzen Trackingstatus-Eintrag in der Historie entlang der Chronologie über zulässige Übergänge (inkl. Überspringen von unpassenden Einträgen) erreicht wird, ohne selbst übersprungen zu werden ODER wenn er chronologisch vor dem aktuell gesetzten Trackingstatus-Eintrag eingereiht wird und ausgehend vom frühesten Eintrag in der Historie entlang der Chronologie über zulässige Übergänge (inkl. Überspringen von unpassenden Einträgen) erreicht wird, ohne selbst übersprungen zu werden ODER wenn er selbst der früheste Eintrag der Historie und als Start-Status zulässig ist.
	►HINWEIS◄ Übergänge zu Trackingstatus-Einträgen, die zeitlich nach dem hinzuzufügenden Eintrag datieren, spielen für die Zulässigkeit des Hinzufügens ausdrücklich keine Rolle.
3. Welcher Trackingstatus-Eintrag gilt nach dem Hinzufügen eines Eintrags als aktuell? Nach dem Hinzufügen eines Trackingstatus-Eintrags wird der aktuelle Trackingstatus des Bezugsobjekts für jeden Trackingstatustyp neu ermittelt, für dessen Matrix das Hinzufügen als zulässig bewertet wurde. Dabei greift abhängig vom Berechnungsmodus für die jeweilige Matrix die rechts beschriebene Logik.	Ausgehend vom frühesten Eintrag der Trackingstatus-Historie wird entlang der Chronologie iterativ nach zulässigen Übergängen (inkl. Überspringen von unpassenden Einträgen) gesucht, bis die Kette abreißt. Der letzte durch eine Kette von zulässigen Übergängen erreichbare Trackingstatus wird für den jeweiligen Trackingstatustyp als aktuell gesetzt.	Ausgehend vom aktuell gesetzten Trackingstatus-Eintrag wird entlang der Chronologie iterativ nach zulässigen Übergängen (inkl. Überspringen von unpassenden Einträgen) gesucht, bis die Kette abreißt. Der letzte durch eine Kette von zulässigen Übergängen erreichbare Trackingstatus wird für den jeweiligen Trackingstatustyp als aktuell gesetzt.
	►WICHTIG◄ Das Hinzufügen eines Trackingstatus-Eintrags zur Historie kann bewirken, dass sich der aktuelle Wert mehrerer Trackingstatus-Attribute des Bezugsobjekts (mit unterschiedlichem Trackingstatustyp) ändert. Der neue aktuelle Trackingstatus-Eintrag muss dabei nicht immer der hinzugefügte Eintrag sein. Außerdem kann es auch vorkommen, dass der angezeigte Trackingstatus-Code sich nicht ändert, aber ein neuer Trackingstatus-Eintrag mit demselben Code referenziert wird. Insofern sind beim Konfigurieren und Testen v. a. komplexerer Szenarien für Trackingstatus-Workflows hohe Aufmerksamkeit für Details und ein umfassendes Verständnis für die hier geschilderten Mechanismen unverzichtbar.