Beschreibung
Folgende Abläufe beschreiben die typischen API-Interaktionen zwischen Auftraggeber und Leistungserbringer im Anwendungsfall "Erneute Auftragsbestätigung versenden". Die fachliche Analyse hat ergeben, dass sich dieser Anwendungsfall in 2 Szenarien aufteilen lassen kann (siehe : GF_Zweite ABM)
Neuen verbindlichen Liefertermin versenden
- Terminverschiebung: Änderung Kundenwunschtermin durch Auftraggeber (Liefertermin verschieben)
Unvorhersehbares Ereignis während der Auftragsrealisierung
- Neue / ergänzende Anschlussinformationen versenden
Bemerkung: der identifizierte Fall "Zweite ABM im Rahmen eines Konnektivitätsauftrages" wird mit der Abbildung des Konnektivitätsauftrages betrachtet / vervollständigt
Titel | Erneute Auftragsbestätigung versenden |
---|---|
Kurzbeschreibung | Folgender Ablauf beschreibt die typischen API- Interaktionen zwischen Auftraggeber und Leistungserbringer im Anwendungsfall "Erneute Auftragsbestätigung versenden". Eine erneute Auftragsbestätigung kann in folgenden Szenarien vorkommen:
Bemerkung: der identifizierte Fall "Erneute Auftragsbestätigung im Rahmen eines Konnektivitätsauftrages" wird mit der Abbildung des Konnektivitätsauftrages betrachtet / vervollständigt Dabei werden die für diesen Ablauf erforderlichen Auftrags-Status durchlaufen und die für diesen Ablauf relevanten Informationen übermittelt. |
Vorbedingung | Der Auftrag befindet sich in der Realisierung, das heißt, die erste Auftragsbestätigung wurde bereits versandt. |
Auslöser | Ein neuer verbindlicher Liefertermin bzw. neue / ergänzende Anschlussinformationen sind vorhanden |
Ergebnis | Eine erneute Auftragsbestätigung wurde versendet |
Ablauf
Stashincludebyfilepath | ||||
---|---|---|---|---|
repoSlug | fit-root | |||
branchId | refs/heads/main | |||
projectKey | TFIT | filepath | tmf622/documentation||
Bitbucket file macro | ||||
|
Beispieldaten
ProductOrderAttributeValueChangeEvent (1)
...
resources Bitbucket file macro collapsible true url https://bitbucket.org/fit-api/fit-api/src/main/
docs/diagrams/ResendABM.pumltmf622/
Handet es sich bei dem Auftrag um die Category Providerwechsel oder Verbundleistung, muss der LE im Falle einer erneute Auftragsbestätigung nach Versenden der ProcessingMessage an den AGauf analog gegenüber dem AGab vorgehen.
Beispieldaten
examples/product-order-4a-attribute-value-change-event-multiple-values.json syntaxHighlighting JSON
Felder | aktualisierte Daten | API Feld | |
---|---|---|---|
Eventdate technisches EventDatum | 2022-05-20T10:45:00 | ||
Anschluss (lineId) | DEU.DTAG.FTYLIQ7PTF | productOrderItem.accessLineId | |
eventTime | |||
verbindlicher Liefertermin (Datum) | 2022-12-19T12:00:00+01:00 (Uhrzeit fachlich nicht relevant, aber technisch erforderlich) | expectedCompletionDate | |
Datum+Zeitfenster | Technikereinsatz(wenn erforderlich, z.B. bei Technikertermin beim Endkunden) | 2022-12-19T08:00:00+01:00 2022-12-19T12:00:00+01:00 | productOrderItem.appointment.validFor.startDateTime productOrderItem.appointment.validFor.endDateTime |
Termin beim Endkunden erforderlich | TRUE | ProductOrderItem.endUserAppointmentIsNecessary |
Beispiel:
Stashincludebyfilepath | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
ProductOrderMilestoneEvent (2)
Bitbucket file macro collapsible true url https://bitbucket.org/fit-api/fit-api/src/main/tmf622/examples/product-order-4b-milestone-event-order-confirmation-update.json syntaxHighlighting JSON
...
Felder | aktualisierte Daten | API Feld | |||
---|---|---|---|---|---|
processingMessageTypeTyp des Product Order Milestone Events | orderConfirmationUpdateprocessingMessageDate | name | |||
Datum und Uhrzeit des Milestones | 2022-05-20T10:46:00 | processingMessageReason | 0005 | processingMessageText | milestoneDate |
Meldecode des Milestones | 0015 | milestoneMessage.code | |||
Meldungstext des Milestones | Der Ausführungstermin wurde vom Leistungserbringer manuell geändert |
...
milestoneMessage.text |