Accept Finally: fachliche Entscheidungslogik

Fachliche Bedeutung
Accept Finally ist die abschließende positive Entscheidung über eine Material Quality Lot
Submission.

Mit dieser Transition bestätigt der verantwortliche Quality Manager, dass die MQLS
endgültig angenommen wird. Die zuvor erteilte Versandfreigabe wird damit zu einer
abschließenden Qualitätsentscheidung.

Die Transition führt von:

 Authorized for Shipment

 zu

 Finally accepted

Die Versandfreigabe allein bedeutet somit noch keine endgültige Annahme. Erst Accept
Finally schließt den positiven MQLS-Lebenszyklus ab.

Fachlicher Auslöser
Der Benutzer führt den Befehl Accept finally für eine bestehende MQLS aus.

Der Befehl enthält keine eigenständigen fachlichen Entscheidungsdaten wie einen
Kommentar, eine Begründung oder ein Akzeptanzdatum. Als Eingabe wird der aktuelle
Processing Context der MQLS abgeleitet, unter anderem mit:

 Remark
 Manufacturing Approval
 Manufacturing Approval Forging Stock
 Method of Manufacturing
 Quality Manager
 Count of Parts
 Additional Email
 Type
 Heat
 Heat Code
 Heat Code Suffix
 Engine Program
 Grouping
 Grouping Applicable
 Forging Stock Supplier
MQLS Key.

Die eigentliche Entscheidung ergibt sich aus dem ausgeführten Command und den
nachfolgend beschriebenen Prüfungen.


Sämtliche Prüfungen
Damit Accept Finally erfolgreich ausgeführt werden kann, müssen mehrere Prüfebenen
erfüllt sein.

Zustandsprüfung
Die MQLS muss sich im Zustand:

 Authorized for Shipment

befinden.

Damit ist fachlich vorausgesetzt, dass der Versand bereits autorisiert wurde. Eine MQLS im
Zustand Forwarded, Returned, Created oder Rejected kann nicht unmittelbar endgültig
angenommen werden.

 Authorized for Shipment

│

│ Accept Finally

▼

 Finally accepted

Rollenprüfung
Der ausführende Benutzer muss die Rolle:

Quality Customer

besitzen.

Formal wird geprüft, ob sich unter den dem aktuellen Benutzer zugeordneten Rollen eine
Rolle mit der Rollen-ID Customer Quality befindet.

Es genügt daher nicht, dass der Benutzer allgemein auf Kundenseite tätig ist oder
administrative Rechte besitzt. Für die Transition Accept Finally ist ausdrücklich die Quality-
Customer-Rolle erforderlich.

Ein Quality Administrator ist durch diese Autorisierungsregel allein nicht zur endgültigen
Annahme berechtigt.

Prüfung des verantwortlichen Quality Managers
Zusätzlich zur Rolle muss der aktuelle Benutzer der für diese MQLS zugeordnete Quality
Manager sein.

Formal wird geprüft:

Current User Context = Quality Manager Context der MQLS

Die beiden Autorisierungsbedingungen gelten gemeinsam:

Der Benutzer besitzt die Rolle Quality Customer.

Der Benutzer ist der zugeordnete Quality Manager dieser konkreten MQLS.


Ein Quality Customer, der nicht als Quality Manager der MQLS eingetragen ist, darf Accept
Finally daher nicht ausführen.

Prüfung eines positiv entschiedenen Approval Requests
Es muss mindestens ein zur MQLS gehörender Approval Request mit dem Status:

Approved

vorhanden sein.

Die MQLS besitzt hierzu eine Projektion auf die Approval Requests, deren Parent Business
Context diese MQLS ist. In dieser Sammlung werden alle Einträge gefiltert, deren Approval
Status „Approved“ lautet.

Die formale Bedingung lautet sinngemäß:

Anzahl der Approval-Request-Einträge

mit Approval Status = Approved

ist größer als 0

Damit ist formal geprüft:

Es existiert mindestens ein positiv entschiedener Approval Request.

Doppelte Verwendung derselben Prüfung

Diese Situation wird in der Transition zweimal verwendet:

 als Requirement für die Verfügbarkeit des Commands
als Guard für die tatsächliche Ausführung der Transition.

Es handelt sich dabei jedoch um dieselbe Situation und nicht um zwei unterschiedliche
Approval-Prüfungen.

Hinweis zum zweiten Approver

Die fachliche Beschreibung des Guards lautet:

Die Transition ist nur möglich, wenn ein positiv entschiedener Approval Request durch den
zweiten Approver existiert.

Die formale Expression prüft allerdings ausschließlich:

 Approval Status ist Approved
Anzahl solcher Einträge ist größer als null.

Eine separate Prüfung auf:

 einen ersten Approver
 einen zweiten Approver
 eine Approver-Reihenfolge
zwei unterschiedliche positive Entscheidungen

ist in der formalen Accept-Finally-Expression nicht enthalten.


Soweit der Status Approved im Approval-Request-Kontext bereits die vollständige
Genehmigungskette einschließlich eines zweiten Approvers repräsentiert, kann dies fachlich
darin enthalten sein. Aus der Accept-Finally-Transition allein ist diese Unterscheidung
jedoch nicht formal nachweisbar.

Insbesondere verlangen Requirement und Guard nicht zwei genehmigte Approval Requests.
Beide referenzieren dieselbe Prüfung „mindestens ein Approved-Eintrag“.

Prüfung der Anwendungskonsistenz
Die MQLS muss die Situation:

Application Is Consistent

erfüllen.

Diese Gesamtprüfung besteht aus drei gemeinsam zu erfüllenden Teilprüfungen:

Application Is Consistent =

vollständige Pflichtangaben

AND konsistente Periodic-Konfiguration

AND konsistente Grouping-Konfiguration

Prüfung der vollständigen Pflichtangaben

Grundlegende Erstellungsattribute
Zunächst müssen weiterhin alle grundlegenden Attribute vorhanden sein, die bereits für die
Existenz einer gültigen MQLS erforderlich sind.

Diese Prüfung ist zugleich die Authority Invariant der MQLS.

Folgende Kontexte beziehungsweise Werte dürfen nicht null sein:

Reference

Die MQLS muss eine identifizierende Referenz besitzen.

Part Number Context

Die MQLS muss mit einem Bauteil beziehungsweise einer Part Number verbunden sein.

Creator Context

Der Ersteller der MQLS muss hinterlegt sein.

Supplier Ownership Context

Der Lieferant, dem die MQLS fachlich zugeordnet ist, muss vorhanden sein.

Der Supplier Ownership Context wird bei der Erstellung übernommen und bleibt
anschließend Eigentumskontext der MQLS.

Vollständige fachliche Pflichtattribute
Zusätzlich zu den Erstellungsattributen müssen folgende MQLS-Felder befüllt sein:


Pflichtattribut Fachliche Bedeutung

Type Typ der MQLS

Engine Program Motoren- beziehungsweise Programmkontext, für den die MQLS gilt

Grouping Applicable Festlegung, ob eine Part-Number-Gruppierung anzuwenden ist

Heat Bezeichnung der Schmelze beziehungsweise des Ausgangsloses

Heat Code Heat Code

Heat Code Suffix Im Modell als Serial Number beschrieben

Manufacturing Approval Kennung der Fertigungsfreigabe

Manufacturing Approval Forging Stock Fertigungsfreigabe für das Forging Stock

Method of Manufacturing Referenz auf die Herstellungsmethode beziehungsweise deren
Dokument

Gemeinsam mit den vier grundlegenden Erstellungsattributen umfasst die formale
Vollständigkeitsprüfung somit dreizehn zwingend vorhandene Werte oder Kontexte.

Nicht generell als Pflichtfeld geprüft

Folgende Felder werden in dieser allgemeinen Pflichtfeldprüfung nicht grundsätzlich als
obligatorisch behandelt:

 Remark
 Additional Email
 Forging Stock Supplier
 Count of Parts
Grouping.

Für Count of Parts und Grouping existieren jedoch bedingte Konsistenzregeln.

Prüfung der Periodic-Konfiguration
Die Periodic-Konfiguration gilt als konsistent, wenn eine der folgenden Alternativen erfüllt
ist:

Alternative 1: MQLS ist nicht periodisch

Type ≠ Periodic

Dann ist für diese Regel keine Teileanzahl erforderlich.

Alternative 2: MQLS ist periodisch

Ist der Typ:

Periodic

muss Count of Parts befüllt sein.

Formal lautet die Prüfung:

Type = Periodic

AND Count of Parts ist nicht null


Abweichung zwischen fachlicher Beschreibung und formaler Regel

Die fachliche Bedeutung der Situation besagt, dass bei einer periodischen MQLS:

Count of Parts größer als null sein muss.

Die formale Expression prüft jedoch lediglich, ob Count of Parts nicht null ist. Eine
tatsächliche Prüfung:

Count of Parts > 0

ist nicht modelliert.

Damit wären nach der formalen Regel beispielsweise auch 0 oder möglicherweise ein
negativer Wert nicht automatisch ausgeschlossen, sofern der zugrunde liegende Datentyp
oder eine andere, hier nicht sichtbare Regel dies nicht verhindert.

Für die Ausführung von Accept Finally ist nach dem SemanticBook die formale Expression
maßgeblich.

Prüfung der Grouping-Konfiguration
Die Grouping-Konfiguration gilt als konsistent, wenn eine der folgenden Alternativen erfüllt
ist:

Alternative 1: Gruppierung ist nicht anwendbar

Grouping Applicable = false

In diesem Fall muss kein Grouping angegeben sein.

Alternative 2: Gruppierung ist anwendbar

Grouping Applicable = true

AND Grouping ist nicht null

Wurde also festgelegt, dass eine Part-Number-Gruppierung verwendet wird, müssen die
zugehörigen gruppierten Part Numbers angegeben sein.

Da Grouping Applicable bereits ein allgemeines Pflichtattribut ist, kann der Wert für die
Gesamtprüfung nicht einfach fehlen.

Authority Invariant
Unabhängig von den Guards muss die MQLS ihre Authority Invariant erfüllen.

Diese fordert erneut das Vorhandensein der grundlegenden Erstellungsattribute:

 Reference
 Part Number Context
 Creator Context
Supplier Ownership Context.

Die Invariant stellt sicher, dass eine MQLS auch bei späteren Transitionen niemals ihren
grundlegenden fachlichen Identitäts- und Eigentumskontext verliert.


Die Prüfung ist teilweise bereits in „Has Full Mandatory Attributes“ enthalten, bleibt aber
zusätzlich als allgemeine Invariante der MQLS wirksam.

Zusammenfassung der Entscheidungslogik
Accept Finally ist fachlich zulässig, wenn alle folgenden Aussagen wahr sind:

MQLS befindet sich in Authorized for Shipment

AND

aktueller Benutzer besitzt die Rolle Quality Customer

AND

aktueller Benutzer ist der zugeordnete Quality Manager

AND

mindestens ein zur MQLS gehörender Approval Request

hat den Status Approved

AND

Reference ist vorhanden

AND

Part Number Context ist vorhanden

AND

Creator Context ist vorhanden

AND

Supplier Ownership Context ist vorhanden

AND

Type ist vorhanden

AND

Engine Program ist vorhanden

AND

Grouping Applicable ist vorhanden

AND

Heat ist vorhanden

AND

Heat Code ist vorhanden

AND

Heat Code Suffix ist vorhanden

AND


Manufacturing Approval ist vorhanden

AND

Manufacturing Approval Forging Stock ist vorhanden

AND

Method of Manufacturing ist vorhanden

AND

bei Type = Periodic ist Count of Parts nicht null

AND

bei Grouping Applicable = true ist Grouping nicht null

Erst wenn diese Bedingungen erfüllt sind, erfolgt der Zustandswechsel zu Finally accepted.

Fachliche Auswirkungen der endgültigen Annahme
Nach erfolgreicher Ausführung wird das Domain Event:

Material Quality Lot Submission Accepted Finally

ausgelöst.

Daraus ergeben sich mehrere fachliche Folgewirkungen.

Zustandsänderung
Die MQLS wechselt in den finalen Zustand:

 Finally accepted

Der positive MQLS-Lebenszyklus ist damit abgeschlossen.

Erzeugung des Final Letter
Aus den MQLS-Informationen wird ein fachlicher Inhalt für einen Final Letter abgeleitet.

Der Final Letter enthält gemäß den modellierten Derivationen unter anderem:

 MQLS Key
 Type
 Count of Parts
 Engine Program
 Heat
 Heat Code
 Heat Code Suffix
Remark.

Der abgeleitete Inhalt wird serialisiert und an den Content Structure Builder übergeben. Als
Content Type wird „Document“ verwendet.

Der Content Structure Builder soll daraus strukturierten Dokumentinhalt erzeugen.


Erzeugung einer Benachrichtigung
Zusätzlich wird eine fachliche Benachrichtigung über die endgültige Annahme abgeleitet.

Die modellierte Notification-Derivation enthält unter anderem:

 MQLS Key
 Engine Program
 Heat
 Heat Code
 Heat Code Suffix
Remark.

Auch dieser Inhalt wird an den Content Structure Builder übergeben, diesmal mit dem
Content Type „Notification“.

Finalisierung des MQLS-Kontexts
Die endgültige Annahme veröffentlicht eine externe Repräsentation des MQLS-Kontexts mit
dem normalisierten Zustand:

Finalized

Damit wird anderen fachlichen Bereichen mitgeteilt, dass der Parent Context MQLS einen
finalen Zustand erreicht hat.

Behandlung verbleibender Approval Requests
Approval Requests, die zu diesem finalisierten MQLS-Parent-Context gehören, werden durch
eine Policy zur Stornierung veranlasst.

Zusätzlich wird deren projizierter normalisierter Parent-Status auf Finalized aktualisiert.

Dies betrifft insbesondere Approval Requests, die trotz endgültiger MQLS-Annahme noch
nicht selbst abgeschlossen wurden.

Finalisierung verbundener Attachments
Attachments, deren Parent Context die MQLS ist, erhalten in ihrer Projektion den
normalisierten Parent-State:

Finalized

Das SemanticBook modelliert an dieser Stelle eine Statusaktualisierung. Eine automatische
Löschung der Attachments findet bei Accept Finally nicht statt.

Finalisierung verbundener Notifications
Auch Notifications, die zur MQLS gehören, erhalten den normalisierten Parent-State:

Finalized