...
| 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 | 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 informiertDabei 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 Auftraggeber einen neuen Termin an (Status "Pending" - Information Required (TAM)), hier nicht dargestellt Der Leistungserbringer sendet an den abgebenden Provider Auftraggeber eine Verzögerungsmeldung (ProcessingMessage JeopardyMessage "delayMessageorderDelay", (VZM-PV))Der weitere Verlauf wird hier nicht mehr betrachtet.) Nach erfolgter Terminverschiebung durch den aufnehmenden Auftraggeber sendet der Leistungserbringer an den abgebenden Auftraggeber eine Information über den neuen Bereitstellungstermin: MilestoneEvent "orderConfirmationUpdate", (erneute ABM-PV)
|
Ablauf
Es gibt keine Möglichkeit, dass eine vom Leistungserbringer eingestellte Kündigung am "Schalttag" fehlschlägt.
...
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)
Bitbucket file macro collapsible true url https://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/product-order-termination-pv-provider-change-4c-jeopardy-event-order-delay.json syntaxHighlighting JSON
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
Bitbucket file macro collapsible true url https://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/product-order-termination-pv-provider-change-4d-attribute-value-change-event-expected-completion-date-after-jeopary-alert.json syntaxHighlighting JSON
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)
Bitbucket file macro collapsible true url https://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/product-order-termination-pv-provider-change-4c-milestone-event-order-second-confirmation-update.json syntaxHighlighting JSON
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) anlegenund deshalb hier nicht aufgeführt: