Beschreibung
| Titel | Auftrag (Providerwechsel / Verbundleistung) anlegen |
|---|---|
| Kurzbeschreibung | Folgender Ablauf beschreibt die typischen Interaktionen zwischen dem aufnehmenden Auftrageber (EKPauf und TNBauf, im zweiten Sequenzdiagramm "Buyer of new line" bezeichnet), dem Leistungserbringer (LE, im zweiten Sequenzdiagramm "Seller of new line" bzw. "Seller of old line" bezeichnet) und dem abgebenden Auftraggeber (EKPab und TNBab, im zweiten Sequenzdiagramm "Buyer of old line" bezeichnet) im Anwendungsfall "Auftrag (Providerwechsel / Verbundleistung) anlegen" von der Anlage des Auftrags bis zu seinem Abschluss. Ein Providerwechsel / Verbundleistung sind 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. Dabei werden die für diesen Ablauf erforderlichen Auftrags-Status durchlaufen und die für diesen Ablauf relevanten Informationen übermittelt. Zu diesen Anwendungsfall sind die zwei folgenden Sequenzen relevant:
|
| Vorbedingung |
|
| Auslöser | Der aufnehmende Auftraggeber legt einen Auftrag für den Providerwechsel bzw. die Verbundleistung beim Leistungserbringer (ANE) an. |
| Ergebnis | Das Produkt wurde erfolgreich bereitgestellt. Voraussetzung für eine erfolgreiche Bereitstellung des Produktes durch den EKPauf ist die Zustimmung des TNBab zum Wechsel des EKP (siehe RespondProviderChange) |
Ablauf
Durchführung der Vorabstimmung
Die Vorabstimmung wird durch die WBCI Schnittstelle zwischen EKPauf und EKPabg durchgeführt.
Der Auftrag enthält als wesentliches Kennzeichen die VorabstimmungsID des EKPauf. Folgende Informationen werden in Bezug auf die Ressource und für die Übernahme für den daraufolgenden Providerwechsel / Verbundleistung Auftrag ausgetauscht.
- Ermittlung des Wechseldatums durch den EKPabg
- Ermittlung der WITA Vertragsnummer (Telekom) bzw LINE-ID (NGAB) , sowie der Technologie der Ressource durch den EKPabg
- Klärung, ob die Ressource übernommen werden soll durch den EKPauf
Produktbeauftragung
Die Produtbeauftragung gliedert sich in zwei Abschnitte
- Die Product Order mit der Category "providerChange" bzw. "providerTechnologyChange", welche vom AGauf an den LE gestellt wird
- Die Product Order mit der Category "terminationProviderChange", welche der LE einstellt.
Während der AGauf die üblichen Möglichkeiten zur Steuerung der ersten Product Order hat (Stornierung, Terminverschiebung etc.), hat der AGab nur am Anfang die Möglichkeit, dem Wechsel zu widersprechen.
Darüber hinausgehende, technisch denkbare Möglichketen der Einflussnahme durch dem AGab (Stornierung, Terminverschiebung etc.) müssen vom LE abgewiesen werden.
Beispieldaten (linker Block, TNBauf ↔ ANE)
Post ProductOrder (providerChange)
ProductOrderStateChangeEvent: Accepted
ProductOrderAttributeValueChange
ProductOrderStateChangeEvent: inProgress (identisch zu Geschäftsfall Neu)
ProductOrderStateChangeEvent: completed (identisch zu Geschäftsfall Neu)
| ProductOrderStateChangeEvent: completed | ||
| fachliche Felder | Daten | API Felder |
| Orderstatus | completed | state |
| fachliches Änderungsdatum | 2022-12-16T10:45:00+01:00 | stateChangeDate |
| technisches EventDatum | 2022-12-16T10:45:00+01:00 | eventTime |
| Grund der Änderung | 0010 "Auftrag ausgeführt." | stateChangeReason.code stateChangeReason.description |
ProductOrderAttributeValueChange (identisch zu Geschäftsfall Neu)
| ProductOrderAttributeValueChange (setzen von startDate) | ||
| fachliche Felder | Daten | API Felder |
| technisches EventDatum | 2022-12-16T10:45:30+01:00 | eventTime |
| Nutzungsdatum | 2022-12-16T10:45:00+01:00 | product.startDate |
ProductOrderStateChangeEvent: closed (identisch zu Geschäftsfall Neu)
| ProductOrderStateChangeEvent: closed | ||
| fachliche Felder | Daten | API Felder |
| Orderstatus | closed | state |
| fachliches Änderungsdatum | 2022-12-16T10:46:00+01:00 | stateChangeDate |
| technisches EventDatum | 2022-12-16T10:46:00+01:00 | eventTime |
| Grund der Änderung | 0010 "Auftrag ausgeführt." | stateChangeReason.code stateChangeReason.description |