Zum Ende des Banners springen
Zum Anfang des Banners springen

1) Negative RespondProviderChange (RUEM-PV)

Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 8 Nächste Version anzeigen »

Beschreibung

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



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 aufnehmenden Provider ein StateChangeEvend "Rejected" (ABBM), hier nicht dargestellt

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

Ablauf

@startuml
autonumber
     
participant tauf as "LE"
     
participant tab as "AG"
     
tauf -> tauf: POST ProductOrder(productOrderItemDelete, category=KUE-LE)
tauf -> tab: ProductOrderCreatedEvent(PO)
tab <- tauf: ProductOrderStateChangeEvent(PO, Acknowleged)
tab <- tauf: ProductOrderAttributeValueChangeEvent(PO, providerChangeInfo, date)
tauf -> tab: ProductOrderStateChangeEvent(PO, Pending)
note right: AKM-PV
tauf -> tab: ProductOrderInformationRequiredEvent(PO, fieldPath=productOrder.ProviderChangeResult.approval)
  
tauf <- tab: POST RespondProviderChange(PO, result.approval=false)
note right: RUEM-PV
tauf -> tab: RespondProviderChangeStateChangedEvent(Acknowledged)
tauf -> tab: RespondProviderChangeStateChangedEvent(inProgress)
tauf -> tab: ProductOrderAttributeValueChangeEvent(PO, productOrder.ProviderChangeResult.approval=false)
tauf -> tab: RespondProviderChangeStateChangedEvent(done)
tauf -> tab: ProductOrderStateChangeEvent(PO, Rejected)
@enduml




Beispieldaten


  • Keine Stichwörter