Beschreibung
| Titel | Auftrag (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 |
Vorbedingung | 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. |
| Auslöser | Der Leistungserbringer legt sich selber einen Kündigungsauftrag an. Schlechtfall: Der abgebende Provider 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 ProductOrderInformationRequiredEventden Provider ein StateChangeEvend "Rejected" (ABBM), hier nicht dargestellt Der Leistungserbringer sendet an den abgebenden Provider 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 |