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. Am Schalttag kann die Bereitstellung nicht erfolgen. |
Vorbedingung |
|
| 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 "orderDelay", (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 |
|---|---|---|
| Typ | orderDelay | JeopardyAlert.name |
| Datum | 2022-12-01T10:40:00+01:00 | JeopardyAlert.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 |
|---|---|---|
| Kategorie | orderConfirmationUpdate | name |
| EventDate | 2022-12-03T11:31:00+01:00 | milestoneDate |
| Meldungscode | 0005 | milestoneMessage.code |
| Meldungstext | Der Ausführungstermin wurde vom Leistungserbringer manuell geändert | milestoneMessage.text |
Der restliche Ablauf ist identisch zum Gutfall Auftrag (Kündigung durch LE, GF PV/VBL) anlegen und deshalb hier nicht aufgeführt: