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: Die Vorabstimmung Die Durchführung
Vorbedingung	Rahmenverträge und Dienstverträge sind vorhanden Der Auftraggeber hat die Verfügbarkeit des Produktes geprüft Mindestens alle Pflichtfelder für eine Product Order im Anwendungsfall Neu sind laut Auftragsmedestruktur gefüllt.
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

Vorabstimmung

@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 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.

@startuml
autonumber
      
box TMF622 Product Order, category=PV
participant eauf as "Buyer of new line: Ordering"
participant tauf as "Seller of new line:  Product Order"
      
box  TMF622 Product Order, category=TerminationProvider
participant leab as "Seller of old line:  Product Order"
participant tab as "Buyer of old line: Ordering"
      
      
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
eauf <-- tauf: 201 Created(acknowledged)
note right: PV
alt Kaufmännische Validierung schlägt fehl
  eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
note right: ABBM
else Kaufmännische Validierung erfolgreich
  eauf <- tauf: ProductOrderStatusChangeEvent(PO, Accepted)
  note right: QEB
  tauf -> leab: notifyKUE
  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]] wird hier inkludiert
  leab ->tauf:notifyRUEM-PV(approval, reason)
  alt negative RUEM-PV
    note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=587837181 1) Negative RespondProviderChange (RUEM-PV)]]
  else positive RUEM-PV
    alt Fehlschlag Technische Validierung und Erteilung
      eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
      note right: ABBM
      tauf -> leab: notifyRejected
      leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
      note right: ABBM-PV
    else Technische Validierung und Erteilung erfolgreich
      eauf <- tauf: POST ProductOrderAttributeValueChangeEvent()
      note right: e.g.: expectedCompletionDate
      eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
      note right: ABM
      tauf -> leab:notifyInProgress
      leab -> tab:POST ProductOrderAttributeValueChangeEvent()
      note right: e.g.: expectedCompletionDate
      leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
      note right: ABM-PV
      alt Fehlschlag während der Realisierung
        note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/display/tfit/2%29+Fehlschlag+beim+Leistungserbringer 2) Fehlschlag beim Leistungserbringer]]
      else Realisierung erfolgreich
        alt Fehlschlag am Schalttag
          note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/display/tfit/3%29+Fehlschlag+am+Schalttag 3) Fehlschlag am Schalttag]]
        else Schaltung erfolgreich
          eauf <- tauf: ProductOrderStateChangeEvent(PO,Completed)
          note right: ERLM
          tauf -> leab:notifyInCompleted
          leab -> tab: ProductOrderStatusChangeEvent(PO2, Completed)
          note right: ERLM-PV
          eauf <- tauf: POST ProductOrderAttributeValueChangeEvent()
          note right: e.g.: productOrderItem.product.startDate
          eauf <- tauf: ProductOrderStateChangeEvent(PO,Closed)
          note right: ENTM
          tauf -> leab:notifyInClosed
          leab -> tab: POST ProductOrderAttributeValueChangeEvent()
          note right: e.g.: productOrderItem.product.terminationDate
          leab -> tab: ProductOrderStatusChangeEvent(PO2, Closed)
          note right: ENTM-PV
        end
      end
    end
  end
end
@enduml

alte Darstellung

Produktbeauftragung

@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 Validierung
  eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
else Happy Path
  eauf <- tauf: ProductOrderStatusChangeEvent(PO, Accepted)
  tauf -> leab: notifyKUE
  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
  leab ->tauf:notifyRUEM-PV(approval, reason)
  alt negative RUEM-PV
    note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=587837181 1) Negative RespondProviderChange (RUEM-PV)]] 
  else Happy Path 
    alt Fehlschlag  + Technische Validierung + Erteilung
      eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
      tauf -> leab: notifyRejected
      leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
    else Happy Path  
      eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
      tauf -> leab:notifyInProgress
      leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
      note right: ABM-PV
      alt Fehlschlag während der Realisierung
        note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/display/tfit/2%29+Fehlschlag+beim+Leistungserbringer 2) Fehlschlag beim Leistungserbringer]] 
      else Happy Path
        alt Fehlschlag am Schalttag
          note over eauf, tauf: Siehe [[https://confluence.t-systems-mms.eu/display/tfit/3%29+Fehlschlag+am+Schalttag 3) Fehlschlag am Schalttag]] 
        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
  end
end
@enduml

ToDos:

Resourcenmodell erweitern (siehe GF Providerwechsel / Verbundleistung)

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

Auftrag (Providerwechsel / Verbundleistung) anlegen