Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Vorbedingung

TitelAuftrag (Kündigung PV) anlegen
Kurzbeschreibung

Folgender Ablauf beschreibt die typischen API- Interaktionen zwischen Auftraggeber und Leistungserbringer im Anwendungsfall "Kündigung durch Leistungserbringer" im Kontext eines Providerwechsel.

Dieser Anwendungsfall behandelt die Kündigung eines Produktes durch den Leistungserbringer. Die Kündigung muss sich auf ein im Bestand des jeweiligen Auftraggebers befindliches Produkt beziehen. Eine Kündigung ist nur dann möglich, wenn keine weiteren offenen Aufträge zum Bestand des Auftraggebers vorliegen. Dies gilt sowohl für Aufträge des bestandsführenden Auftraggebers als auch von anderen Auftraggebern (z.B. beim Geschäftsfall Providerwechsel). Voraussetzung für den Geschäftsfall Kündigung durch Auftraggeber ist ein bestehender Rahmenvertrag zwischen dem Auftraggeber und dem Leistungserbringer sowie die Angabe aller ausführungsrelevanten Daten. 

Entsprechung: KUE/DT in WITA, KUE/LE in SPRI

Rahmenvertrag ist vorhanden

Das zu kündigende Produkt befindet sich im Bestand des Auftraggebers

Es liegen keine offenen Aufträge zum Produkt vor.

Der Auftraggeber hat sich beim Leistungserbringer mindestens für die Category "KUE-LE" registriert. Dadurch wird er über ProductOrderCreateEvent von jedem neuen Kündigungsauftrag informiert.Dabei werden die für diesen Ablauf erforderlichen Auftrags-Status durchlaufen und die für diesen Ablauf relevanten Informationen übermittelt.

Der abgebende Provider lehnt die Anfrage zum Providerwechsel ab (im Beispiel mit der Begründung: falsche Vorabstimmungs-ID)



Vorbedingung

  • Rahmenverträge und Dienstverträge sind vorhanden
  • aufnehmender Provider hat einen Wechselgeschäftsfall für PV oder VBL eingestellt
  • Mindestens alle Pflichtfelder für eine Product Order im Anwendungsfall PV oder VBL sind laut Auftrags-/Meldungsstruktur (download) gefüllt.
Auslöser

Der Leistungserbringer legt sich selber einen Kündigungsauftrag an.

Schlechtfall: Der abgebende Provider Auftraggeber lehnt die Anfrage zum Providerwechsel ab (im Beispiel mit der Begründung: falsche Vorabstimmungs-ID)

Ergebnis

Nach Eingang der negativen RespondProviderChange (RUEM-PV) wird der Auftrag wird seitens des Leistungserbringers abgebrochen - Status Rejected

Der Leistungserbringer sendet an den aufnehmen

ProductOrderInformationRequiredEvent

den Provider Auftraggeber ein StateChangeEvend "Rejected" (ABBM), hier nicht dargestellt

Der Leistungserbringer sendet an den abgebenden Provider Auftraggeber ein StateChangeEvend "Rejected" (ABBM-PV)

...

Der Gesamtablauf mit einer negativen RUEM-PV ist hier beschrieben: 1) Negative RespondProviderChange (RUEM-PV)


Beispieldaten (rechter Block, ANE ↔ TNBab)

rote Schriftfarbe = Abweichungen im Vergleich zum Gutfall


Folgende Beispieldaten sind identisch zum Gutfall Auftrag (Kündigung durch LE, GF PV/VBL) anlegen und deshalb hier nicht aufgeführt:

ProductOrder (Kündigung LE, GF PV/VBL)

...

ProductOrderInformationRequiredEvent

TaskResource: RespondProviderChange (RUEM-PV)

Bitbucket file macro
collapsibletrue
urlhttps://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/respond-provider-change-termination-pv-provider-change-0a-error-preagreement-id.json
syntaxHighlightingJSON

fachliche Felder

Daten

API Felder

Datum des Versands der TaskRessource2022-05-11T10:35:00+01:00RespondProviderChange.requestedPostedDate
AblehnungFALSERespondProviderChange.approval
AntwortcodeKVE

RespondProviderChange.responseReason[0].code

AntworttextVorabstimmungs-ID fehlerhaft

RespondProviderChange.responseReason[0].description


Folgende Beispieldaten sind wieder identisch zum Gutfall Auftrag (Kündigung durch LE, GF PV/VBL) anlegen und deshalb hier nicht aufgeführt:

RespondProviderChangeStateChangeEvent: Acknowledged

...

RespondProviderChangeStateChangeEvent: Done

ProductOrderAttributeValueChangeEvent

Bitbucket file macro
collapsibletrue
urlhttps://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/product-order-termination-pv-provider-change-5a-negative-attribute-value-change.json
syntaxHighlightingJSON

fachliche FelderDatenAPI Felder
technisches EventDatum 2022-05-11T10:39:00+01:00eventTime
AblehnungFALSEProductOrder.RespondProviderChangeInfo.approval
AntwortcodeKVE

ProductOrder.RespondProviderChangeInfo.responseReason[0].code

AntworttextVorabstimmungs-ID fehlerhaft

ProductOrder.RespondProviderChangeInfo.responseReason[0].description

ProductOrderStateChangeEvent: Rejected (ABBM-PV)

Bitbucket file macro
collapsibletrue
urlhttps://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/respond-provider-change-termination-pv-2-state-change-event-rejected.json
syntaxHighlightingJSON

fachliche FelderDaten API Felder
Orderstatus rejectedstate 
fachliches Änderungsdatum 2022-05-11T10:40:00+01:00stateChangeDate 
technisches EventDatum2022-05-11T10:40:00+01:00eventTime
Grund der Änderung

0041

"Der abgebende Provider hat die Kündigung seines Bestandes abgelehnt."

stateChangeReason.code

stateChangeReason.description