Tutorial P2P Expert - Verzögerung und Skontoverlust

TL;DR
Ziel: Verzögerungen aus der Wareneingangsprüfung auf nachgelagerte Rechnungen und Zahlungen übertragen und daraus verlorenes Skonto berechnen.
Voraussetzungen: Der Capacity Bottleneck auf wareneingang_pruefung ist konfiguriert und erzeugt Backlog.
Ergebnis: Verzögerte Prüfungen verschieben zugehörige Rechnungen und Zahlungen. skonto_frist_am bleibt fest; wird sie überschritten, werden skonto_genutzt und skonto_verlust_eur neu berechnet.

Fachliche Fragestellung

Im vorherigen Use Case haben wir einen lokalen Engpass erzeugt:

Wareneingang

→ begrenzte Prüfkapazität

→ Backlog

→ verspätete wareneingang_pruefung

Damit ist zunächst aber nur die Prüfung selbst verspätet.

In einem realen P2P-Prozess wirkt eine solche Verzögerung häufig weiter:

Eine Rechnung kann später freigegeben werden, die Zahlung verschiebt sich und eine vorhandene Skontofrist kann verpasst werden.

Die eigentliche fachliche Frage lautet deshalb:

Welche finanziellen Auswirkungen kann ein operativer Kapazitätsengpass im Wareneingang auf spätere Prozessschritte haben?

Gewünschtes Datenbild

Ohne Bottleneck:

Wareneingang

→ Wareneingangsprüfung

→ Rechnung

→ Rechnungsfreigabe

→ Zahlung

→ Skontofrist eingehalten

Mit Bottleneck:

Wareneingang

→ Backlog in der Prüfung

→ verspätete Wareneingangsprüfung

→ Rechnung verschiebt sich

→ Zahlung verschiebt sich

→ skonto_frist_am wird überschritten

→ Skonto geht verloren

Damit entsteht eine durchgängige Kausalkette:

Kapazitätsengpass

→ Prozessverzögerung

→ verspätete Zahlung

→ finanzieller Verlust

1. Advanced-Bereich öffnen

Bleibe unter: 07 Capacity Bottleneck und öffne: Advanced

Dort finden wir den Abschnitt: 5. Propagate the delay

Die Smart Data Forge kann hier eine durch den Backlog entstandene Verzögerung auf nachgelagerte Objekte desselben Cases übertragen. Sobald die notwendigen Felder gesetzt sind, ist die Propagation aktiv; einen separaten Ein-/Aus-Schalter gibt es nicht.

2. Verzögerung über rechnung_bezug weitergeben

Für unser P2P-Modell verwenden wir: Variant B — via bridge table

Der Grund dafür ist die relationale Struktur.

Zwischen Wareneingang und Rechnung existiert die Tabelle: rechnung_bezug

Sie verbindet: wareneingang mit: rechnung

und ermöglicht dadurch die Zuordnung des entstandenen Prüf-Delays zur richtigen Rechnung.

Konfiguriere:

Bridge table (N:M):
rechnung_bezug

Bridge → activity key:
wareneingang_id

Bridge → downstream-object-1 key:
rechnung_id

Die vorbereitete Expert-Konfiguration verwendet genau diese Bridge-basierte Propagation.

3. Rechnung als erstes Downstream-Objekt konfigurieren

Setze:

Downstream object 1 — table: rechnung

Downstream object 1 — time column (shifts): rechnung_freigegeben_am

Damit kennt die Forge die Rechnung, die von der verspäteten Prüfung betroffen ist.

Bei der Bridge-Variante geht die Engine noch einen Schritt weiter: Sie übernimmt den berechneten Prüf-Delay für die zugehörige Rechnung und verschiebt deren Timestamps um denselben Zeitraum. Dadurch bleiben die relativen Abstände innerhalb der Rechnung erhalten.

Vereinfacht:

Prüfung ursprünglich: Dienstag

Prüfung durch Backlog: Donnerstag

→ Delay: etwa 2 Tage

Dann verschiebt sich auch die zugehörige Rechnung entsprechend nach hinten.

4. Zahlung als zweites Downstream-Objekt konfigurieren

Setze anschließend:

Downstream object 2 — table: zahlung

Downstream object 2 — time column (shifts): zahlung_ausgefuehrt_am

Downstream object 2 → downstream-object-1 key: rechnung_id

Damit wird der gleiche Delay auch auf die Zahlung übertragen.

Die Engine verschiebt die Zahlung um denselben berechneten Zeitversatz wie die zugehörige Rechnung.

Die Kausalkette lautet jetzt:

wareneingang_pruefung

→ Delay

→ rechnung

→ gleicher Delay

→ zahlung

Warum wird derselbe Delay weitergegeben?

Angenommen, eine Prüfung wird durch den Backlog um drei Tage verzögert.

Ohne Propagation könnte anschließend trotzdem eine Rechnung zum ursprünglich geplanten Zeitpunkt existieren.

Das wäre kausal unplausibel: Prüfung verspätet

aber: Rechnung unverändert früh

Mit Delay Propagation wird deshalb die tatsächlich entstandene Verzögerung weitergetragen.

Aus:

+3 Tage bei der Prüfung

werden auch:

+3 Tage bei den nachgelagerten Objekten.

Dadurch bleibt der Prozess zeitlich konsistent.

5. Skontofrist als feste Deadline behandeln

Jetzt öffnen wir:

6. Recalculate dependent values

Dieser Bereich berechnet Werte neu, die sich aus der zuvor erzeugten Verzögerung ergeben.

Aktiviere: Deadline stays fixed (does not move along)

und wähle als:

Deadline/due-date column (downstream object 1): skonto_frist_am

Die Rechnung und Zahlung sollen sich durch den Bottleneck verschieben.

Die ursprüngliche Skontofrist dagegen bleibt bestehen.

Die Engine nimmt skonto_frist_am deshalb ausdrücklich von der Timestamp-Verschiebung aus, wenn die Deadline als fest konfiguriert ist.

Fachlich entsteht damit: skonto_frist_am bleibt unverändert

während: zahlung_ausgefuehrt_am nach hinten verschoben wird.

Erst dadurch kann ein tatsächlicher Skontoverlust entstehen.

6. Ergebnisfelder für Skonto konfigurieren

Setze:

Used flag (downstream object 2, optional): skonto_genutzt

Calculated result column, e.g. lost discount (downstream object 2): skonto_verlust_eur

Base amount (downstream object 1): brutto_betrag

Percentage (downstream object 1): skonto_prozent

Die Expert-Konfiguration verwendet genau diese Felder zusammen mit der festen skonto_frist_am.

Wann gilt das Skonto als verloren?

Nach der Delay Propagation prüft die Forge, ob:

rechnung_freigegeben_am > skonto_frist_am

oder:

zahlung_ausgefuehrt_am > skonto_frist_am

gilt.

Ist mindestens eine dieser Bedingungen erfüllt, wird:

skonto_genutzt = nein gesetzt.

Zusätzlich berechnet die Forge:

skonto_verlust_eur = brutto_betrag × skonto_prozent / 100

Die Berechnung ist direkt Bestandteil des erzeugten Capacity-SQL.

Der Unterschied zum Simple-Use-Case

Im Simple-Teil haben wir bewusst eine feste Verzögerung modelliert:

pruefer_team = Kreditorenbuchhaltung

→ +12 Tage

→ erhöhtes Skontorisiko.

Das war eine direkt definierte Ursache.

Im Expert-Use-Case entsteht die Verzögerung dagegen dynamisch:

zu viele Wareneingänge

→ zu wenig Prüfkapazität

→ Backlog

→ tatsächlicher Prüf-Delay

→ Delay Propagation

→ verspätete Zahlung

→ Skontoverlust.

Der finanzielle Effekt hängt dadurch nicht mehr von einem fest eingestellten Delay allein ab, sondern von der tatsächlichen Auslastung der Ressource.

Die fertige Konfiguration

5. Propagate the delay

6. Recalculate dependent values

Capacity SQL erneut erzeugen

Nach der Erweiterung klicken wir erneut auf:

Generate capacity SQL

Das erzeugte Skript enthält jetzt nicht mehr nur die Kapazitäts- und Backlog-Logik.

Es enthält zusätzlich:

1. Verschiebung der Wareneingangsprüfung

2. Propagation auf die zugehörige Rechnung

3. Propagation auf die Zahlung

4. Prüfung der festen Skontofrist

5. Berechnung des verlorenen Skontos.

Die gesamte Expert-Logik wird damit in einem nachgelagerten Capacity-SQL ausgeführt.

Was sollte ich später in Noreja sehen?

Nun wird der Bottleneck nicht nur lokal an der Wareneingangsprüfung sichtbar.

Es sollte eine durchgängige Wirkungskette entstehen:

pruefkapazitaet_ueberschritten = 1

→ höhere verzoegerung_slots

→ spätere Rechnung

→ spätere Zahlung

→ häufiger skonto_genutzt = nein

→ positiver skonto_verlust_eur.

Damit lassen sich beispielsweise folgende Fragen untersuchen:

Welche Prozessursache führt zu verlorenen Skontobeträgen?

Wie viel Skonto geht bei Cases mit Prüfplatz-Rückstau verloren?

Wie stark beeinflusst der Bottleneck die gesamte P2P-Durchlaufzeit?

Sind Fälle mit mehreren verschobenen Prüfungsterminen besonders teuer?

Der entscheidende Punkt ist:

Wir haben den finanziellen Verlust nicht zufällig auf Cases verteilt.

Er ist eine kausale Folge des zuvor erzeugten Prozessengpasses.

Typische Fehler / darauf achten

Deadline stays fixed aktivieren.
Wird die Skontofrist zusammen mit der Rechnung verschoben, verschwindet der gewünschte finanzielle Effekt.

Die richtige Bridge verwenden.
rechnung_bezug verbindet Wareneingang und Rechnung und ermöglicht dadurch die Zuordnung des individuellen Delays.

Skontoverlust nicht direkt zufällig generieren.
skonto_verlust_eur soll aus der tatsächlichen Fristüberschreitung entstehen.

Capacity SQL nach data.sql ausführen.
Capacity, Backlog, Propagation und Skonto-Neuberechnung sind Teil des nachgelagerten SQL-Schritts.

Ergebnis

Wir haben jetzt eine vollständige synthetische Ursache-Wirkungs-Kette erzeugt:

begrenzte Prüfkapazität

→ Backlog

→ verspätete Wareneingangsprüfung

→ verspätete Rechnung

→ verspätete Zahlung

→ Skontofrist überschritten

→ Skontoverlust in EUR.

Damit zeigt der Expert Mode, wie aus einem operativen Prozessproblem ein messbarer finanzieller Effekt entstehen kann.

Nächster Schritt

Im letzten Expert-Use-Case modellieren wir einen anderen Mechanismus:

Mehrere Rechnungen werden nicht sofort einzeln verarbeitet, sondern in einem regelmäßigen gemeinsamen Lauf gesammelt.

Dafür verwenden wir:

08 Bundling

und erzeugen einen:

wöchentlichen Freigabelauf am Freitag um 09:00 Uhr.

Weiter: Tutorial P2P Expert -  Bündelung und Freigabelauf