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:
|
Vorbedingung |
|
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 Failed Der Leistungserbringer sendet an den aufnehmenden Provider ein StateChangeEvend "Failed" (ABBM) Der Leistungserbringer sendet an den abgebenden Provider ein StateChangeEvend "Failed" (ABBM-PV), hier nicht dargestellt |
Ablauf
Beispieldaten (linker Block, TNBauf ↔ ANE)
ProductOrderStateChangeEvent: inProgress
ProductOrderStateChangeEvent: inProgress | ||
fachliche Felder | Daten | API Felder |
Orderstatus | inProgress | state |
fachliches Änderungsdatum | 2022-05-20T10:40:00+01:00 | stateChangeDate |
technisches EventDatum | 2022-05-20T10:40:00+01:00 | eventTime |
Grund der Änderung | 0000 "Keine Änderung zum Auftrag" | stateChangeReason.code stateChangeReason.description |
Historisierung acknowledged fachliches Änderungsdatum Grund der Änderung | 2022-05-11T10:31:00+01:00 0000 "Keine Änderung zum Auftrag" | stateChangeHistory.@type = StateChange stateChangeHistory.changeDate stateChangeHistory.changeReason.code stateChangeHistory.changeReason.description |