Zum Ende des Banners springen
Zum Anfang des Banners springen

3) Fehlschlag am Schalttag

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 16 Nächste Version anzeigen »

Beschreibung

TitelAuftrag (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.

Am Schalttag kann die Bereitstellung nicht erfolgen. 



Vorbedingung

  • Rahmenverträge und Dienstverträge sind vorhanden
  • AGauf hat einen Wechselgeschäftsfall für PV oder VBL eingestellt
  • Mindestens alle Pflichtfelder für eine Product Order im Anwendungsfall Neu sind laut Auftragsmedestruktur gefüllt.
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)),

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

Nach erfolgter Terminverschiebung durch den aufnehmenden Provider sendet der Leistungserbringer an den abgebenden Provider eine Information über den neuen Bereitstellungstermin: ProcessingMessage "orderConfirmationUpdate", (erneute ABM-PV)

 

Ablauf

Es gibt keine Möglichkeit, dass eine vom Leistungserbringer eingestellte Kündigung am "Schalttag" fehlschlägt.

Ein PV bzw. eine VBL kann lediglich auf aufnehmender Seite am Schalttag fehlschlagen.

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

ProductOrderJeopardyAlertEvent (VZM-PV)

fachliche Felder

Daten

API Felder

TyporderDelayJeopardyAlert.name
Datum2022-12-01T10:40:00+01:00JeopardyAlert.alertDate
Meldungscode

6009

JeopardyAlert.JeopardyAlertMessage.code
Meldungstext

Endleitung ist defekt

JeopardyAlert.JeopardyAlertMessage.text

ProductOrderAttributeValueChangeEvent

fachliche Felder

Daten

API Felder

Eventdate 2022-12-03T11:30:00+01:00 
verbindlicher Liefertermin (Datum)2022-12-19T12:00:00+01:00
(Uhrzeit fachlich nicht relevant, aber technisch erforderlich)

expectedCompletionDate

ProductOrderMilestoneEvent (erneute ABM-PV)

fachliche Felder

Daten

API Felder

KategorieorderConfirmationUpdatename
EventDate2022-12-03T11:31:00+01:00milestoneDate
Meldungscode0005milestoneMessage.code
MeldungstextDer Ausführungstermin wurde vom Leistungserbringer manuell geändertmilestoneMessage.text

Der restliche Ablauf ist identisch zum Gutfall Auftrag (Kündigung durch LE, GF PV/VBL) anlegen und deshalb hier nicht aufgeführt:


  • Keine Stichwörter