Seitenvergleich

Folgender Ablauf beschreibt die typischen API Interaktionen zwischen dem aufnehmenden Auftrageber (EKPauf und TNBauf, aka AGauf), dem Leistungserbringer (LE, aka ANE) und dem abgebenden Auftraggeber (EKPab und TNBab, aka ABab) für die Anwendungsfälle "Auftrag (Providerwechsel / Verbundleistung) anlegen - Schlechtfall Negative RespondProviderChange (RUEM-PV)".

Zu diesen Anwendungsfall sind zwei Sequenzen relevant:

• Die Vorabstimmung
• Die Durchführung

• Rahmenverträge und Dienstverträge sind vorhanden
• Der Auftraggeber hat die Verfügbarkeit des Produktes geprüft
• der AGab hat sich beim LE für Kündigungen durch den Leistungserbringer registriert (siehe Auftrag (Kündigung durch LE, GF PV/VBL) anlegen)

Der aufnehmende Auftraggeber legt einen Auftrag für den Providerwechsel bzw. die Verbundleistung beim Leistungserbringer (ANE) an.

Schlechtfall:Am Schalttag kann die Bereitstellung nicht erfolgen. 

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 "OrderDelayorderDelay", (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)

Der weitere Verlauf wird hier nicht mehr betrachtet.