WAS ISTTATSÄCHLICHVOR ORT.

# Agentische Vorgehensweise zur Bestandsklärung

## 1. Ausgangssituation und fachliches Ziel

Ich bin **Material Responsible** für einen bestimmten **Customer-Supplied Raw Material Stock** bei einem Lieferanten.

Es besteht die Vermutung, dass der aktuell ausgewiesene Bestand nicht dem tatsächlich beim Lieferanten vorhandenen physischen Bestand entspricht.

Das fachliche Ziel ist deshalb zunächst **nicht die unmittelbare Korrektur des ausgewiesenen Bestands**, sondern die belastbare Feststellung des tatsächlichen Bestands und dessen Abgleich mit dem für den relevanten Zeitpunkt aufgezeichneten Bestand.

Dazu ist eine gezielte Inventur des betroffenen Materials einzuleiten.

---

## 2. Request for Inventory anlegen

Als Material Responsible erstelle ich einen **Request for Inventory** für genau den betroffenen Customer-Supplied Raw Material Stock.

Dabei werden festgelegt:

- der betroffene Supplier,
- der zu prüfende Customer-Supplied Raw Material Stock,
- das gewünschte **Requested Result Due Date**,
- der **Inventory Request Reason**, hier die vermutete Bestandsabweichung.

Die Erstellung ist nur zulässig, wenn der ausgewählte Materialbestand zum ausgewählten Supplier gehört und ich selbst der **Material Responsible** dieses Bestands bin. Das Requested Result Due Date muss mindestens einen Kalendertag in der Zukunft liegen.

Durch **Create Request for Inventory** entsteht ein Request im Zustand:

`Request for Inventory = Created`

Ich werde dabei als **Requester** des Requests hinterlegt.

---

## 3. Request in Bearbeitung geben

Da ich Requester des Requests bin, führe ich anschließend **Start Processing Request for Inventory** aus.

Dadurch wechselt der Request:

`Created → Under Approval`

Mit diesem Übergang entsteht das Event **Request for Inventory Processing Started**.

Dieses Event löst die Policy **Create Approval Request When Processing Starts** aus.

Dadurch wird genau ein **Approval Request** für meinen Request for Inventory erzeugt. Die **Potential Inventory Representatives** bilden dabei den Approver-Kontext.

---

## 4. Approval Request wird automatisch weitergeleitet

Für die konkrete Approval-Usage **Request for Inventory** ist die Usage-Konfiguration

`Forward Created Approval Requests = true`

gesetzt.

Damit ist die entsprechende Voraussetzung für die allgemeine Approval-Policy erfüllt.

Der neu erzeugte Approval Request verbleibt deshalb nicht in `Created`. Die Policy **Approval Request Policy Forward Created** wird anwendbar und führt die Transition **Forward Created Approval Request** aus:

`Approval Request: Created → In Process`

Das dadurch entstehende Forwarded-Ereignis löst wiederum die Policy **Approval Request Forwarded Work** aus.

Dadurch wird **Work für die Assigned Approvers** erzeugt.

Die Wirkungskette endet deshalb nach der Erzeugung des Approval Requests ausdrücklich noch nicht.

---

## 5. Approval-Entscheidung abwarten und fachlich auswerten

Der nächste fachliche Sachverhalt ist die Entscheidung eines berechtigten Approvers.

Hier entstehen zwei unterschiedliche Zweige.

### Negative Approval-Entscheidung

Wird der Approval Request negativ entschieden, wird die Policy **Reject Request When Approval Is Negative** relevant.

Dadurch wird der Request for Inventory auf:

`Rejected`

gesetzt.

Die angeforderte Inventur wird auf Basis dieses Requests nicht durchgeführt.

Für diesen Zweig ist damit der fachliche Endpoint erreicht.

### Positive Approval-Entscheidung

Bei einer positiven Approval-Entscheidung wird die Policy **Start Execution When Approval Is Positive** ausgelöst.

Der Request for Inventory wechselt:

`Under Approval → In Process`

Damit beginnt die eigentliche Durchführung der angeforderten Bestandsklärung.

---

## 6. Inventur aus dem genehmigten Request erzeugen

Der Beginn der Ausführung löst weitere Policies aus.

Zunächst wird über **Create Interim Inventory Plan When Execution Starts** ein **Interim Inventory Plan** für den genehmigten Request angelegt.

Der genehmigende User wird dabei als **Inventory Representative** des Plans berücksichtigt.

Parallel wird der Requester darüber informiert, dass sich sein Request nun **In Process** befindet.

Aus dem für den Request erzeugten Interim Inventory Plan wird anschließend über **Create Supplier Inventory for Approved Request** eine **Supplier Inventory** für genau den betroffenen Supplier angelegt.

Die Supplier Inventory behält dabei die explizite Beziehung zum ursprünglichen Request for Inventory.

---

## 7. Das angefragte Material wird automatisch in den Zählumfang aufgenommen

Da die Supplier Inventory aus einem genehmigten Request for Inventory entstanden ist, wird der angefragte Customer-Supplied Raw Material Stock automatisch als **Material Participation** aufgenommen.

Die Policy **Add Requested Material Participation** führt dazu, dass genau der Materialbestand, dessen Bestand geklärt werden soll, in den Zustand:

`Material Participation = Selected`

übernommen wird.

Voraussetzung ist unter anderem, dass der Materialbestand weiterhin aktiv ist und zum Supplier der Supplier Inventory gehört.

Damit ist der Zählumfang für diesen Request bereits eindeutig festgelegt.

---

## 8. Supplier Inventory geht unmittelbar in Counting

Da es sich um eine aus einem genehmigten Request for Inventory erzeugte Supplier Inventory handelt, wird der normale vorgelagerte Scope-Aufbau übersprungen.

Die Policy **Start Requested Supplier Inventory Counting** führt die Supplier Inventory unmittelbar von:

`Active → Counting`

Die Phasen zur normalen Verifikation bzw. Vorbereitung des Zählumfangs werden hierbei nicht benötigt, weil der genehmigte Request bereits exakt bestimmt, welches Material gezählt werden soll.

Der Beginn von Counting löst wiederum mehrere fachliche Folgen aus:

Es wird ein **Supplier Inventory Count** im Zustand `Active` erzeugt und der Supplier wird darüber informiert, dass die Bestandszählung durchgeführt werden soll.

---

## 9. Lieferant erfasst den physischen Bestand

Ein berechtigter **Supplier Inventory Count User** des betreffenden Suppliers erfasst für die ausgewählte Material Participation einen **Supplier Inventory Material Count**.

Der Material Count enthält den Count Date sowie die tatsächlich gezählten Bestandsmengen.

Das Modell berücksichtigt dabei Mengen in den Bestandskategorien:

`Raw Material Stock`  
`Finished Goods Stock`  
`Work In Progress Stock`  
`Scrap Stock`  
`Transport Stock`

Nicht angegebene Bestandskategorien werden mit einer Menge von null berücksichtigt.

Für die Bestandsklärung ergibt sich daraus die physisch gezählte Gesamtmenge des Materials.

---

## 10. Supplier reicht das Zählergebnis ein

Der Supplier Inventory Count kann erst mit **Submit Supplier Inventory Count** eingereicht werden, wenn für jede ausgewählte Material Participation ein entsprechender Material Count vorhanden ist.

Da der Request for Inventory gezielt den betroffenen Materialbestand in den Count Scope eingebracht hat, muss insbesondere für diesen Materialbestand ein Zählergebnis vorhanden sein.

Mit der Einreichung wechselt der Supplier Inventory Count:

`Active → Submitted`

Die zugehörigen Material-Count-Positionen werden ebenfalls auf `Submitted` gesetzt.

Gleichzeitig löst die Einreichung die Policy **Start Reconciliation When Count Submitted** aus.

Die Supplier Inventory wechselt dadurch automatisch:

`Counting → Reconciliation`

---

## 11. Material Responsible wird in die Reconciliation einbezogen

Mit dem Eintritt der Supplier Inventory in `Reconciliation` wird die Policy **Notify Reconciliation Participants When Reconciliation Starts** ausgelöst.

Dabei werden die an der Reconciliation beteiligten Personen informiert, insbesondere:

die Material Responsibles der ausgewählten Material Participations, der Inventory Responsible sowie der Inventory Representative.

Damit werde ich als Material Responsible darüber informiert, dass das Zählergebnis für mein Material zur fachlichen Abstimmung bereitsteht.

---

## 12. Material Reconciliation durchführen

Für den eingereichten Material Count wird eine **Supplier Inventory Material Reconciliation** angelegt.

Die Material Reconciliation verbindet:

den vom Supplier gemeldeten physischen Materialbestand mit dem aufgezeichneten **Customer-Supplied Raw Material Stock** für den relevanten Referenzzeitpunkt.

Der fachlich entscheidende Wert ist die:

**Stock Difference**

Sie ergibt sich aus:

`Counted Total Quantity – Recorded Total Stock Quantity`

Die Counted Total Quantity umfasst dabei die physisch erfassten Mengen über die relevanten Bestandskategorien.

Die Recorded Total Stock Quantity stammt aus dem **Recorded Stock Level**, der sowohl zum betrachteten Customer-Supplied Raw Material Stock als auch zum **Relevant Reference Time** der Reconciliation passen muss.

Damit wird aus der ursprünglichen Vermutung eine quantitativ belegbare Bestandsabweichung oder die Feststellung, dass keine entsprechende Abweichung besteht.

---

## 13. Zählergebnis fachlich beurteilen

Als Material Responsible beurteile ich nun das Ergebnis der Material Reconciliation.

Dabei bestehen zwei fachliche Möglichkeiten.

### Zählergebnis ist nachvollziehbar

Ist das Zählergebnis belastbar und steht genau ein passender Recorded Stock Level für den relevanten Materialbestand und Referenzzeitpunkt zur Verfügung, kann ich als Material Responsible **Complete Material Reconciliation** ausführen.

Nur der Material Responsible der betreffenden Material Participation ist zur Completion berechtigt.

Die Material Reconciliation wechselt:

`Active → Completed`

Dadurch wird die zugehörige Material-Reconciliation-Projektion der Supplier Inventory auf **Finalized** gesetzt und der ermittelte **Absolute Stock Difference Value** unveränderlich übernommen.

Damit liegt ein fachlich abgeschlossenes und quantifiziertes Ergebnis der Bestandsklärung für dieses Material vor.

### Zählergebnis ist nicht plausibel oder eine Nachzählung ist erforderlich

Bestehen weiterhin Zweifel am Zählergebnis, schließe ich die Material Reconciliation nicht ab.

Stattdessen führe ich als Material Responsible **Mark Material Reconciliation For Revision** aus.

Die Material Reconciliation wechselt:

`Active → RevisionMarked`

Dadurch wird die Policy **Notify Inventory Responsible About Revision Mark** relevant.

Der **Inventory Responsible** wird darüber informiert, dass für dieses Material eine Revision bzw. Nachzählung erforderlich ist.

---

## 14. Nachzählung anfordern

Die eigentliche Revision des Supplier Inventory Count darf nicht vom Material Responsible selbst gestartet werden.

Nur der **Inventory Responsible** kann **Request Supplier Inventory Count Revision** ausführen.

Voraussetzung dafür ist, dass mindestens eine zugehörige Material Reconciliation auf `RevisionMarked` steht.

Durch die Anforderung der Revision wechselt der Supplier Inventory Count:

`Submitted → Revision`

Gleichzeitig werden die markierte Material Reconciliation und der dazugehörige Material Count in den Revisionszustand überführt.

Der Supplier kann daraufhin die betroffene Zählung korrigieren bzw. erneut durchführen.

---

## 15. Revidiertes Zählergebnis erneut prüfen

Der Supplier reicht anschließend den korrigierten Supplier Inventory Count über **Submit Supplier Inventory Count Revision** erneut ein.

Der Supplier Inventory Count geht wieder nach:

`Submitted`

Die betroffene Material Reconciliation erhält die revidierten Zähldaten und wird automatisch wieder:

`Revision → Active`

Damit steht sie erneut zur fachlichen Beurteilung durch den Material Responsible bereit.

Ich prüfe das aktualisierte Ergebnis erneut.

Ist das Ergebnis weiterhin nicht belastbar, kann die Reconciliation erneut für Revision markiert werden.

Ist das Ergebnis belastbar und existiert genau ein passender Recorded Stock Level, schließe ich die Material Reconciliation ab.

Damit entsteht ein fachlich modellierter Wiederholungszyklus:

`Active`
→ `RevisionMarked`
→ `Count Revision`
→ `Supplier korrigiert Count`
→ `Revision`
→ `Active`
→ erneute Prüfung

bis eine belastbare Bestandsklärung vorliegt.

---

## 16. Ergebnis der Bestandsklärung

Mit dem Abschluss der Material Reconciliation ist für das betreffende Material fachlich festgestellt:

- welche Gesamtmenge der Supplier physisch gemeldet hat,
- welcher Recorded Stock Level zum relevanten Referenzzeitpunkt vorliegt,
- welche **Stock Difference** daraus resultiert,
- und welcher **Absolute Stock Difference Value** für die weitere Supplier Inventory maßgeblich ist.

Wichtig ist dabei:

Die im Semantic Book beschriebene Wirkung der abgeschlossenen Material Reconciliation besteht in der **Finalisierung der Reconciliation und der Speicherung der Bestandsabweichung**.

Aus der hier verfolgten Policy-Kette ergibt sich dagegen **keine direkte Policy, die aufgrund des Abschlusses der Material Reconciliation automatisch den ausgewiesenen Customer-Supplied Raw Material Stock auf den gezählten Wert umschreibt**.

Die Bestandsklärung und eine gegebenenfalls erforderliche Bestandsfortschreibung sind deshalb fachlich voneinander zu unterscheiden.

---

## 17. Supplier Inventory Reconciliation abschließen

Nach Finalisierung aller Material Reconciliations kann die Supplier Inventory die Reconciliation verlassen.

Dies darf nur der **Inventory Responsible** des Suppliers über **Finish Supplier Inventory Reconciliation** ausführen.

Dafür müssen alle Material Reconciliations der Supplier Inventory `Finalized` sein.

Zusätzlich verlangt das Modell die jeweils erforderlichen genehmigten Approval Requests.

Während `Reconciliation` sind immer erforderlich:

**Inventory Responsible Approval** und  
**Team Lead Approval**.

Zusätzlich wird bei einem gesamten absoluten Differenzwert von mehr als **30.000 EUR** ein **Department Head Approval** erforderlich.

Bei mehr als **100.000 EUR** ist zusätzlich ein **Division Head Approval** erforderlich.

Positive und negative Materialabweichungen werden für diese Schwellenwerte mit ihrem absoluten Wert berücksichtigt und kompensieren sich nicht gegenseitig.

Erst wenn die erforderlichen Approvals als `Approved` vorliegen, kann der Inventory Responsible ausführen:

`Supplier Inventory: Reconciliation → Reporting`

Das Semantic Book definiert diese Approved Approval Requests als Voraussetzung für das Beenden der Reconciliation. In der hier verfolgten Wirkungskette ist jedoch keine eindeutige Folge-Policy modelliert, die allein aufgrund des Eintritts dieser Approval-Required-Situationen automatisch die dazugehörigen Approval Requests erzeugt. Deshalb darf der Agent deren Erzeugung nicht eigenständig ergänzen oder unterstellen.

Sind die erforderlichen Approved Approval Requests noch nicht vorhanden, liegt an dieser Stelle ein fachlicher Endpoint aufgrund einer nicht erfüllten Voraussetzung vor.

---

## 18. Supplier Inventory und Request abschließen

Befindet sich die Supplier Inventory in `Reporting`, kann sie vom **Inventory Representative** des zugehörigen Inventory Plan abgeschlossen werden.

Durch:

`Complete Supplier Inventory`

wechselt die Supplier Inventory nach:

`Completed`

Dieses Ergebnis löst weitere Policies aus.

Insbesondere wird der exakt zu dieser Supplier Inventory gehörende **Request for Inventory** automatisch abgeschlossen:

`Request for Inventory: In Process → Completed`

Außerdem wird der zugehörige Supplier Inventory Count automatisch in seinen terminalen Zustand `Completed` überführt.

Durch die Completion des Request for Inventory wird der Requester über den Abschluss seines Requests informiert.

Damit ist auch der ursprüngliche Auftrag zur Bestandsklärung formal abgeschlossen.

---

# Agentische Gesamtlogik

Der Agent verhält sich damit nicht nach dem Muster:

`Bestand erscheint falsch → Bestand korrigieren`

sondern:

`Bestandsabweichung vermutet`
→ `gezielte Inventur beantragen`
→ `Approval durchführen`
→ `physische Zählung erzeugen`
→ `Zählergebnis mit Recorded Stock Level abgleichen`
→ `bei Zweifeln Nachzählung veranlassen`
→ `belastbares Ergebnis finalisieren`
→ `Supplier Inventory abschließen`
→ `Request for Inventory abschließen`

Die zentrale Verantwortung des Material Responsible liegt dabei insbesondere darin, die Bestandsklärung anzustoßen und das materialbezogene Reconciliation-Ergebnis fachlich zu beurteilen.

---

# Vollständige Policy-Kette

`Vermutete Abweichung des Customer-Supplied Raw Material Stock`
→ `Create Request for Inventory`
→ `Request = Created`
→ `Start Processing Request for Inventory`
→ `Request = Under Approval`
→ `Create Approval Request When Processing Starts`
→ `Approval Request = Created`
→ `Forward Created Approval Requests = true`
→ `Approval Request Policy Forward Created`
→ `Approval Request = In Process`
→ `Approval Request Forwarded Work`
→ `Work für Assigned Approvers`
→ `{Negative Approval → Reject Request → Request = Rejected → Endpoint | Positive Approval → Start Execution}`
→ `Request = In Process`
→ `{Requester Notification | Create Interim Inventory Plan}`
→ `Create Supplier Inventory for Approved Request`
→ `Add Requested Material Participation`
→ `Material Participation = Selected`
→ `Start Requested Supplier Inventory Counting`
→ `Supplier Inventory = Counting`
→ `{Create Supplier Inventory Count | Notify Supplier}`
→ `Supplier erstellt Material Count`
→ `Submit Supplier Inventory Count`
→ `{Material Count = Submitted | Start Reconciliation}`
→ `Supplier Inventory = Reconciliation`
→ `Notify Reconciliation Participants`
→ `Create Material Reconciliation`
→ `Bestandsvergleich: Counted Total Quantity – Recorded Total Stock Quantity`
→ `{plausibel → Complete Material Reconciliation | nicht plausibel → Mark For Revision}`
→ bei Revision: `Notify Inventory Responsible`
→ `Request Supplier Inventory Count Revision`
→ `Supplier Inventory Count = Revision`
→ `Supplier korrigiert Zählung`
→ `Submit Supplier Inventory Count Revision`
→ `Material Reconciliation = Active`
→ `erneute fachliche Prüfung`
→ gegebenenfalls erneute Revision
→ `Complete Material Reconciliation`
→ `Material Reconciliation Projection = Finalized + Absolute Stock Difference Value`
→ `erforderliche Supplier-Inventory-Approvals müssen Approved sein`
→ `Finish Supplier Inventory Reconciliation`
→ `Supplier Inventory = Reporting`
→ `Complete Supplier Inventory`
→ `{Request for Inventory = Completed | Supplier Inventory Count = Completed | Supplier Inventory Projection = Finalized}`
→ `Notify Requester`
→ **Endpoint**