Ansprechpartner, Kontakte werden an verschieden Stellen, in verschiedenen Anwendungsfälle benötigt.
...
| Drawio | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Erweiterungen
| Erweiterung | Beschreibung (Englisch) | Source | |
|---|---|---|---|
| RelatedPartyRefOrValue | Related Entity reference. A related party defines a party described by reference or by value linked to a specific entity. | TMF 4.0 Schemas | übernommen |
| Individual.salutation | standard wording used to address an individual | FIT extension | übernommen |
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.