Beschreibung
| Titel | Auftrag (Providerwechsel / Verbundleistung) anlegen |
|---|
| Kurzbeschreibung | 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 - Gutfall". Zu diesen Anwendungsfall sind zwei Sequenzen relevant: - Die Vorabstimmung
- Die Durchführung
|
|---|
| Vorbedingung | - 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) anlegen)
|
|---|
| 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 |
|---|
Ablauf
Durchführung der Vorabstimmung
Die Vorabstimmung wird von der WBCI übernommen.
Sie wird zwischen EKPauf und EKPab durchgeführt und dient der
- Ermittlung des Wechseldatums
- Ermittlung der WITA Vertragsnummer
- Ermittlung der VorabstimmungsID
- Klärung, ob die Ressource übernommen werden soll
@startuml
autonumber
box WBCI
participant eauf as "EKP auf"
participant eab as "EKP ab"
eauf -> eab: VA-KUE-MRN
eauf <- eab: REUM-VA
eauf -> eab: AK-MTR
Produktbeauftragung
Die Produtbeauftragung gliedert sich in
- Die Product Order mit der Category "Providerwechsel" bzw. "Verbundleistung", welche vom gestellt wird
- Die Product Order mit der Category Kündigung durch "Leistungserbringer", 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.
@startuml
autonumber
box Product Order vom Typ PV (PO)
participant eauf as "EKP auf + TNB auf (AG auf)"
participant tauf as "ANE (LEauf)"
box (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "ANE (LEab)"
participant tab as "TNB ab + EKPab (AG ab)"
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
note right: PV
alt Fehlschlag Kaufmännische + Technische Validierung
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
else Happy Path
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Acknowleged)
tauf -> leab: notifyKUE
leab -> leab: POST ProductOrder(productOrderItemDelete, category=KUE-LE)
note over leab, tab: Die Sequenz [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=547957140 Auftrag (Kündigung durch LE, GF PV/VBL) anlegen]] hier wird includiert
alt Fehlschlag Erteilung
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
tauf -> leab: notifyRejected
leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
else Happy Path
leab ->tauf:notifyRUEM-PV(approval, reason)
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
alt Fehlschlag während der Realisierung
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Failed)
tauf -> leab: notifyFailed
leab -> tab: ProductOrderStatusChangeEvent(PO2, Failed)
else Happy Path
eauf <- tauf: ProductOrderStateChangeEvent(PO,Completed)
tauf -> leab:notifyInCompleted
leab -> tab: ProductOrderStatusChangeEvent(PO2, Completed)
note right: ERLM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,Closed)
tauf -> leab:notifyInClosed
leab -> tab: ProductOrderStatusChangeEvent(PO2, Closed)
note right: ENTM-PV
end
end
end
@enduml
ToDos:
