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

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 "Providerwechsel" bzw. "Verbundleistung", welche vom AGauf an den LE 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.

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