Beschreibung
| Titel | Auftrag (Kündigung PV) anlegen |
|---|---|
| Kurzbeschreibung | Folgender Ablauf beschreibt die typischen Interaktionen zwischen Auftraggeber und Leistungserbringer im Anwendungsfall "Kündigung durch Leistungserbringer" im Kontext eines Providerwechsel. 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 |
|
| Auslöser | Der Leistungserbringer legt sich selber einen Kündigungsauftrag an. Schlechtfall: Der abgebende 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 seitens des Leistungserbringers abgebrochen - Status Rejected Der Leistungserbringer sendet an den aufnehmenden Auftraggeber ein StateChangeEvend "Rejected" (ABBM), hier nicht dargestellt Der Leistungserbringer sendet an den abgebenden Auftraggeber ein StateChangeEvend "Rejected" (ABBM-PV) |
Ablauf
Es gibt kein Szenario, in dem eine RUEM-PV außerhalb eines PV bzw. einer VBL geschickt wird.
Daher gibt es keinen eigenständigen Anwendungsfall für diesen Use Case.
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)
ProductOrderStateChangeEvent: Acknowledged
ProductOrderAttributeValueChange (setzen von Antwortfrist)
ProductOrderStateChangeEvent: Pending (AKM-PV)
ProductOrderInformationRequiredEvent
TaskResource: RespondProviderChange (RUEM-PV)
fachliche Felder | Daten | API Felder |
|---|---|---|
| Datum des Versands der TaskRessource | 2022-05-11T10:35:00+01:00 | RespondProviderChange.requestedPostedDate |
| Ablehnung | FALSE | RespondProviderChange.approval |
| Antwortcode | KVE | RespondProviderChange.responseReason[0].code |
| Antworttext | Vorabstimmungs-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: InProgress
RespondProviderChangeStateChangeEvent: Done
ProductOrderAttributeValueChangeEvent
| fachliche Felder | Daten | API Felder |
| technisches EventDatum | 2022-05-11T10:39:00+01:00 | eventTime |
| Ablehnung | FALSE | ProductOrder.RespondProviderChangeInfo.approval |
| Antwortcode | KVE | ProductOrder.RespondProviderChangeInfo.responseReason[0].code |
| Antworttext | Vorabstimmungs-ID fehlerhaft | ProductOrder.RespondProviderChangeInfo.responseReason[0].description |
ProductOrderStateChangeEvent: Rejected (ABBM-PV)
| fachliche Felder | Daten | API Felder |
| Orderstatus | rejected | state |
| fachliches Änderungsdatum | 2022-05-11T10:40:00+01:00 | stateChangeDate |
| technisches EventDatum | 2022-05-11T10:40:00+01:00 | eventTime |
| Grund der Änderung | 0041 "Der abgebende Provider hat die Kündigung seines Bestandes abgelehnt." | stateChangeReason.code stateChangeReason.description |