Versionen im Vergleich

Schlüssel

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

...

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: Am Schalttag kann die Bereitstellung nicht erfolgen. 

Ergebnis

Der Leistungserbringer fordert beim aufnehmenden Provider einen neuen Termin an (Status "Pending" - Information Required (TAM)), hier nicht dargestellt

Der Leistungserbringer sendet an den abgebenden Provider eine Verzögerungsmeldung (ProcessingMessage "OrderDelaydelayMessage", (VZM-PV))

Der weitere Verlauf wird hier nicht mehr betrachtet.

...

Siehe 3) Fehlschlag am Schalttag



Beispieldaten

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)

RespondProviderChangeStateChangeEvent: Acknowledged

RespondProviderChangeStateChangeEvent: InProgress

RespondProviderChangeStateChangeEvent: Done

ProductOrderStateChangeEvent: inProgress

ProductOrderProcessingMessageEvent (VZM-PV)

fachliche Felder

Daten

API Felder

TypdelayMessageproccesingMessageType
Datum2022-12-01T10:40:00+01:00proccesingMessageDate
Meldungscode

6009

proccesingMessageReason.code
Meldungstext

Endleitung ist defekt

processingMessageReason.description