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 - Schlechtfall Negative RespondProviderChange (RUEM-PV)". 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. Schlechtfall: Der abgebende Provider lehnt die Anfrage zum Providerwechsel ab (im Beispiel mit der Begründung: falsche Vorabstimmungs-ID)
Ergebnis	Nach Eingang der negativen RespondProviderChange (RUEM-PV) wird der Auftag wird seitens des Leistungserbringers abgebrochen - Status Rejected Der Leistungserbringer sendet an den aufnehmenden Provider ein StateChangeEvend "Rejected" (ABBM) Der Leistungserbringer sendet an den abgebenden Provider ein StateChangeEvend "Rejected" (ABBM-PV)

Ablauf

@startuml
autonumber
        
box TMF622 Product Order, category=PV/VBL
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
     
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Accepted)
note right: QEB
tauf -> leab: notifyKUE
leab -> leab: POST  ProductOrder(productOrderItemDelete, category=terminationProviderChange)
leab --> leab: 201 Created(acknowledged)
note right: TEQ
     
leab -> tab: ProductOrderCreatedEvent(PO2)
tab <- leab: ProductOrderStateChangeEvent(PO2, Accepted)
note right: QEB
tab <- leab: ProductOrderAttributeValueChangeEvent(PO2, providerChangeInfo, date)
leab -> tab: ProductOrderStateChangeEvent(PO2, Pending)
note right: AKM-PV
leab -> tab: ProductOrderInformationRequiredEvent(PO2, ProviderChangeResult.approval)
     
leab <- tab: POST RespondProviderChange(PO2, result.approval=false)
note right: RUEM-PV
leab -> tab: RespondProviderChangeStateChangedEvent(inProgress)
leab -> tab: ProductOrderAttributeValueChangeEvent(PO2)
note right: ProviderChangeResult.approval=false
tab <- leab: ProductOrderStateChangeEvent(PO2, Accepted)
leab -> tab: RespondProviderChangeStateChangedEvent(done)
    
leab -> tab: ProductOrderStateChangeEvent(PO2, Rejected)
note right: ABBM-PV
tauf <- leab: notifyPVRejected
eauf <- tauf: ProductOrderAttributeValueChangeEvent(PO)
note right: ProviderChangeResult.approval=false
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
note right: ABBM
@enduml

Beispieldaten (linker Block, TNBauf ↔ ANE)

Post ProductOrder (providerChange) - identisch zum Gutfall

siehe Auftrag (Providerwechsel / Verbundleistung) anlegen , Abschnitt "Beispieldaten (linker Block, TNBauf ↔ ANE)", Kapitel "Post ProductOrder (providerChange)"

ProductOrderStateChangeEvent: Accepted - identisch zum Gutfall

siehe Auftrag (Providerwechsel / Verbundleistung) anlegen , Abschnitt "Beispieldaten (linker Block, TNBauf ↔ ANE)", Kapitel "ProductOrderStateChangeEvent: Accepted"

ProductOrderAttributeValueChange (19)

Farbcodierung:

rote Schriftfarbe = Abweichungen im Vergleich zum Event ProductOrderAttributeValueChange aus dem Gutfall im Vorfeld des ProductOrderStateChange inProgress

fachliche Felder	Daten	API Felder
technisches EventDatum	2022-05-11T10:33:00+01:00	eventTime
Supplier-Daten
Rolle	orderManagementSupplierContact	relatedParty.role
Anrede	Frau	relatedParty.salutation
Vorname	Lisa	relatedParty.givenName
Nachname	Bach	relatedParty.familyName
Telefonnummer	0221/789456	relatedParty/contactMedium.mediumType = "PhoneContactMedium" relatedParty/contactMedium/characteristic.contactType = "fixed" relatedParty/contactMedium/characteristic.phoneNumber
Mobilfunknummer	0178/78787878	relatedParty/contactMedium.mediumType = "PhoneContactMedium" relatedParty/contactMedium/characteristic.contactType = "mobile" relatedParty/contactMedium/characteristic.phoneNumber
Email-adresse	l.bach@example.net	relatedParty/contactMedium.mediumType = "EmailContactMedium" relatedParty/contactMedium/characteristic.contactType = "email" relatedParty/contactMedium/characteristic.emailAddress
Daten vom abgebenden Provider
Rolle	handingOverProvider	relatedParty.role
Providername	1&1 Internet AG	relatedParty.name
Zustimmung Providerwechsel	FALSE	productOrder/providerChangeInfo.approval
Antwortcode	KVE	productOrder/providerChangeInfo.responseReason.code
Antworttext	Vorabstimmungs-ID fehlerhaft	productOrder/providerChangeInfo.responseReason.description

ProductOrderStateChangeEvent: rejected (19+1)

ProductOrderStateChangeEvent: rejected
fachliche Felder	Daten	API Felder
Orderstatus	rejected	state
fachliches Änderungsdatum	2022-05-20T10:40:00+01:00	stateChangeDate
technisches EventDatum	2022-05-20T10:40:00+01:00	eventTime
Grund der Änderung	0041 "Der abgebende Provider hat die Kündigung seines Bestandes abgelehnt."	stateChangeReason.code stateChangeReason.description

1) Negative RespondProviderChange (RUEM-PV)

Beschreibung

Ablauf

Beispieldaten (linker Block, TNBauf ↔ ANE)

ProductOrderAttributeValueChange (19)

ProductOrderStateChangeEvent: rejected (19+1)