Zum Ende des Banners springen
Zum Anfang des Banners springen

1) Negative RespondProviderChange (RUEM-PV)

Zum Ende der Metadaten springen
  • Erstellt von Former user , zuletzt geändert von Former user am Okt. 23, 2024
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 32 Nächste Version anzeigen »

Beschreibung

TitelAuftrag (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: 201 Created(acknowledged)
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: 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 FelderDatenAPI Felder
technisches EventDatum 2022-05-11T10:33:00+01:00eventTime
Supplier-Daten
Rolle orderManagementSupplierContactrelatedParty.role
AnredeFraurelatedParty.salutation
VornameLisarelatedParty.givenName
NachnameBachrelatedParty.familyName
Telefonnummer0221/789456

relatedParty/contactMedium.mediumType = "PhoneContactMedium"

relatedParty/contactMedium/characteristic.contactType = "fixed"

relatedParty/contactMedium/characteristic.phoneNumber 

Mobilfunknummer0178/78787878

relatedParty/contactMedium.mediumType = "PhoneContactMedium"

relatedParty/contactMedium/characteristic.contactType = "mobile"

relatedParty/contactMedium/characteristic.phoneNumber 

Email-adressel.bach@example.net

relatedParty/contactMedium.mediumType = "EmailContactMedium"

relatedParty/contactMedium/characteristic.contactType = "email"

relatedParty/contactMedium/characteristic.emailAddress

Daten vom abgebenden Provider
RollehandingOverProvider

relatedParty.role

Providername

1&1 Internet AG

relatedParty.name

Zustimmung ProviderwechselFALSE

productOrder/providerChangeInfo.approval

AntwortcodeKVE

productOrder/providerChangeInfo.responseReason.code

AntworttextVorabstimmungs-ID fehlerhaft

productOrder/providerChangeInfo.responseReason.description

ProductOrderStateChangeEvent: rejected (19+1)

ProductOrderStateChangeEvent: rejected
fachliche FelderDaten API Felder
Orderstatus rejectedstate 
fachliches Änderungsdatum 2022-05-20T10:40:00+01:00stateChangeDate 
technisches EventDatum2022-05-20T10:40:00+01:00eventTime
Grund der Änderung

0041

"Der abgebende Provider hat die Kündigung seines Bestandes abgelehnt."

stateChangeReason.code

stateChangeReason.description

  • Keine Stichwörter

Datenschutz
Impressum
Feedback