Ansprechpartner, Kontakte werden an verschieden Stellen, in verschiedenen Anwendungsfälle benötigt.

Folgende Übersicht definiert eine Übergreifende Struktur für die Abbildung der Ansprechpartner / Kontakte

Party

...

Drawio
border true diagramName Party Resource Model simpleViewer false links auto tbstyle top lbox true diagramWidth 18421371 revision 46

PartyRole (not used)

Die TMF PartyRole ist, zum jetzigem Zeitpunkt, nicht in den FIT APIs verwendet. Diese wird hier im Kontext der Analyse hier dennoch beschrieben, falls diese zu einem späteren Zeitpunkt eingeführt werden sollte.

RelatedParty(RefOrValue) = RelatedPartyOrPartyRole

Erweiterungen

Verwendung von RelatedPartyOrPartyRole

Party vs PartyRole

TMF definiert 2 Objekte, um Parteien abzubilden. Party ist das Kernobjekt, welches die Person oder die Organisation und seine statischen und kontextübergreifenden Eigenschaften beschreibt. PartyRole erlaubt es ergänzend, im Bestand, Rollen fest zu definieren und Rollen bezogene Eigenschaften und Beziehungen zu dokumentieren.

RelatedParty.role vs PartyRole.role

In den TMF APIs wird typischerweise der Bezug von einer API Resource auf die Partei, durch die Rolle dieser Partei im Kontext der Beziehung qualifiziert. Dazu wird das Related<Entity> Pattern verwendet, welches im der Related<Entity>.role Property, die Rolle dokumentiert. Hier ist zu beachten, dass die Rolle mit der API Resource persistiert wird, nicht mit der referenzierten Partei.

Beispiel: Carrier ist der Auftrageber für einen Auftrag. Die Rolle "Auftraggeber" macht nur im Kontext des Auftrages Sinn. Der selbe Carrier kann auch "Besteller" für einen anderen Auftrag sein. Diese vorgangsbezogene Rolle wird Related<Entity>.role abgebildet. Die Rolle ist nicht mit dem Carrier fest definiert, und wird nur mit dem Auftrag persistiert.

Das PartyRole Konstrukt dagegen, erlaubt es, aus Party Management Sicht (statischer Bestand), Rollen fest zu definiert und effizient zu dokumentiert. Für einen bestimmten Service Provider, kann es Sinn machen Carrier über klar definiertete Rollen (Kunde, Lieferant, ...) und rollenbezogene Eigenschaften und Beziehungen (Kontaktdaten, Konten, Verträge, ...) zu verwalten. Im Rahmen von FIT, ist der Fokus auf Interaktionen zwischen Carrier gesetzt. Somit sind primär die Rollen im Kontext der Vorgänge (Auftrag, Entstörung, ...) relevant. Rollen werden also in der Regel an der Related<Entity>.role Property abgebildet

(Related)PartyRefOrPartyRoleRef → (Related)PartyOrPartyRole

In den TMF V5 APIs wird in der Regel das Objekt RelatedPartyRefOrPartyRoleRef bzw. PartyRefOrPartyRoleRef verwendet, um auf Parteien über Ref Objekte zu referenzieren. Das heißt, dass die TMF APIs, den Anwendern immer die Möglichkeit überlässt auf Parteien direkt über PartyRef oder indirekt über PartyRoleRef zu referenzieren.

In den FIT Beispielen gehen wir davon aus, dass direkt auf eine Partei verwiesen wird. Es besteht aber auch die Anforderung, Parteien als Wert an den Vorgängen zu dokumentieren und somit, das RefOrValue Pattern zu verwenden. Strikt gesehen, hätten wir (Related)PartyRefOrPartyRoleRef mit (Related)PartyRefOrValue ersetzen können. Um aber die Kompatibilität mit den TMF APIs zu behalten, haben wir uns entschiedenen, das TMF Standard Konstrukt (Related)PartyRefOrPartyRoleRef mit dem RefOrValue Pattern zu erweitern. Und (Related)PartyRefOrPartyRoleRef + RefOrValue ist in den TMF Schemas als (Related)PartyOrPartyRole bereits vordefiniert.

In den FIT APIs wurde also (Related)PartyRefOrPartyRoleRef durch (Related)PartyOrPartyRole ersetzt.