Beschreibung

Titel	Auftrag abbrechen
Kurzbeschreibung	Folgender Ablauf beschreibt die typischen API-Interaktionen zwischen Auftraggeber und Leistungserbringer im Anwendungsfall "Auftrag abbrechen". Der Leistungserbringer bricht Auftragsrealisierung ab und meldet dem Auftraggeber den Abbruch zurück.
Vorbedingung	Der abzubrechende Auftrag wurde angelegt und ist noch nicht abgeschlossen (closed, rejected or failed)
Auslöser	Folgende Auslöser des Auftragsabbruches können vorkommen: Negative kaufmännische Validierung Negative technische Validierung / Erteilung Erfolglose Terminanforderung (TAM und MTAM) Scheitern der Auftragsrealisierung
Ergebnis	Die Bereitstellung wurde abgebrochen und der Abbruch dem Auftraggeber gemeldet

Ablauf

Untervariante "Auftrag Providerwechsel und Verbundleistung" abbrechen

Happy Path siehe hier: Auftrag (Providerwechsel / Verbundleistung) anlegen

Im folgenden sollen die Auswirkungen eines Abbruchs auf einen PV bzw. eine VBL dargestellt werden.

Im Fall

Erfolglose Terminanforderung (TAM und MTAM)
Scheitern der Auftragsrealisierung

gibt es keine besondere Einflüsse:

AKM-PV und RUEM-PV sind bereits ausgetauscht
die RUEM-PV war positiv
Der Statuswechsel Rejected bzw. Failed wird auf beide POs propagiert.

Erfolgt die Ablehnung aufgrund der Validierungen, ist das Zusammenspiel jeweils wie folgt:

Kaufmännische Validierung

Es kommt nicht zum Einstellen einer "Kündigung durch den LE":

Abbruch PV während der kaufm. Validierung

@startuml
autonumber
 
box Product Order vom Typ PV (PO)
participant eauf as "EKP auf + TNB auf (AG auf)"
participant tauf as "ANE (LEauf)"
 
 
 
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
note right: PV
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)

Technische Validierung

Abbruch eines Providerwechsels während er technischen Validierung

@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
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Acknowleged)
tauf -> leab: notifyKUE
leab -> leab: POST  ProductOrder(productOrderItemDelete, category=KUE-LE) 
leab -> tab: ProductOrderCreatedEvent(PO2)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Acknowleged)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Pending)
leab -> tab: ProductOrderInformationRequiredEvent(PO2, fieldPath=productOrder.TNBabApproval)
note right: AKM-PV 
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Rejected)
tauf -> leab: notifyRejected
leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
note right: ABBM-PV

Untervariante "Kündigung durch LE, GF PV und VBL" abbrechen

Happy Path siehe Auftrag (Kündigung durch LE, GF PV/VBL) anlegen

Keine rechtzeitige RUEM-PV

Schickt der AG die RUEM-PV nicht rechtzeitig, wird die Kündigung vom LE zurückgewiesen.

Auch der Eltern-Auftrag PV bzw. VBL wird dann zurückgewiesen (hier nicht dargestellt).

Keine rechtzeitige RUEM-PV

@startuml
autonumber
 
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "LE"
participant tab as "AG"
 
 
leab -> leab: POST  ProductOrder(productOrderItemDelete, category=KUE-LE) 
leab -> tab: ProductOrderCreatedEvent(PO2)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Acknowleged)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Pending)
leab -> tab: ProductOrderInformationRequiredEvent(PO2, fieldPath=productOrder.TNBabApproval)
note right: AKM-PV
leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
note right: ABBM-PV

Ablehnung der RespondProviderChange durch LE

Der LE kann die Task Resource ablehnen.

Die Kündigung ( und der sie auslösende PV- bzw. VBL-Auftrag) werden dann vom LE zurückgewiesen.

Ablehnung RespondProviderChange

@startuml
autonumber
 
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "LE"
participant tab as "AG"
 
 
leab -> leab: POST  ProductOrder(productOrderItemDelete, category=KUE-LE) 
leab -> tab: ProductOrderCreatedEvent(PO2)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Acknowleged)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Pending)
leab -> tab: ProductOrderInformationRequiredEvent(PO2, fieldPath=productOrder.TNBabApproval)
note right: AKM-PV
leab <- tab: POST ResondProviderChange(approval, reason)
note right: RUEM-PV
leab -> tab: ResondProviderChangeStatusChangedEvent(Acknowledged)
leab -> tab: ResondProviderChangeStatusChangedEvent(Rejected) 
leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
note right: ABBM-PV

Ablehnung durch den AG

Der AG kann die AKM-PV negativ beantworten.

Auch in diesem Fall werden die Kündigung ( und der sie auslösende PV- bzw. VBL-Auftrag) dann vom LE zurückgewiesen:

Ablehung durch den AG

@startuml
autonumber
 
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "LE"
participant tab as "AG"
 
 
leab -> leab: POST  ProductOrder(productOrderItemDelete, category=KUE-LE) 
leab -> tab: ProductOrderCreatedEvent(PO2)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Acknowleged)
leab -> tab: ProductOrderStatusChangeEvent(PO2, Pending)
leab -> tab: ProductOrderInformationRequiredEvent(PO2, fieldPath=productOrder.TNBabApproval)
note right: AKM-PV
leab <- tab: POST ResondProviderChange
leab -> tab: ResondProviderChangeStatusChangedEvent(Acknowledged)
leab -> tab: ResondProviderChangeStatusChangedEvent(InProgress)
leab <- tab: ResondProviderChangeAttributeValueChange(approval, reason)
leab -> tab: ProductOrderAttributeValueChange(PO2, approval, reason)
leab -> tab: ResondProviderChangeStatusChangedEvent(Done)
note right: RUEM-PV
leab -> tab: ProductOrderStatusChangeEvent(PO2, Rejected)
note right: ABBM-PV

Business Rule

In der Category "KUE-LE" gibt es nur den Ablauf "Scheitern der Auftragsrealisierung" (siehe Beschreibung, Auslöser).

Die Abläufe

Negative kaufmännische Validierung
Negative technische Validierung / Erteilung
Erfolglose Terminanforderung (TAM und MTAM)

werden im Geschäftsfall "KUE-LE" nicht unterstützt.

Beispieldaten

ProductOrderAttributeValueChange (Alternativprodukt/korrigierter Standort)
eventDate/changeDate	2022-05-11T10:30:30
Wiedervorlagetermin	2023-01-16T10:00:00+01:00	earliestOrderRetry
Alternativprodukt	alternateProductOffering
Alternativprodukt	FTTH L2 PON 1500 1000	name
StandortA Korrektur		RelatedPlaceRefOrValue
StandortA Korrektur	AlternateAddress	role
	Rheinhausen	city
	DEU	country
	59055	postcode
	Biberweg	streetName
	2	streetNr
	b	streetNrSuffix

ProductOrderStateChangeEvent: Abbruch bei kaufmännischer/technischer Validierung
fachliche Felder	Daten	API Felder
orderstatus	rejected	state
eventDate/changeDate	2022-05-11T10:31:00


ProductOrderStateChangeEvent: nach erfolgloser TAM/MTAM
orderstatus	cancelled	state
eventDate/changeDate	2022-05-11T10:31:00


ProductOrderStateChangeEvent: Abbruch bei Auftragsrealisierung
orderstatus	failed	state
eventDate/changeDate	2022-05-11T10:31:00


ProductOrderAttributeValueChange (Fehlauftragsnummer bei Auftragsklammer)
eventDate/changeDate	2022-05-11T10:30:00
Fehlauftragsnummer	relatedRejectedProductOrder	productOrder/productOrderChacteristic.name
Externe Auftragsnummer eines anderen abgewiesenen Auftrages mit der gleichen Auftragsklammer	EXT123456789	productOrder/productOrderChacteristic.value

Auftrag abbrechen