---
title: "Tutorial P2P Expert - Verzögerung und Skontoverlust"
url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-expert-verzogerung-und-skontoverlust"
language: "de"
last_updated: "2026-09-22T10:43:04.478Z"
---

# Tutorial P2P Expert - Verzögerung und Skontoverlust

Vom lokalen Kapazitätsengpass zur kausalen Verzögerung von Rechnung und Zahlung.

> **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

![](https://cdn-assets.productfruits.com/9ec319c5-dc7c-4c78-a1eb-b6afaa9f709e)

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

![](https://cdn-assets.productfruits.com/1bbbde88-3bbd-4ec6-bd92-90969af1ffdc)

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`

| Einstellung | Wert |
| --- | --- |
| Variant | `Variant B — via bridge table` |
| Bridge table | `rechnung_bezug` |
| Bridge → activity key | `wareneingang_id` |
| Bridge → downstream-object-1 key | `rechnung_id` |
| Downstream object 1 | `rechnung` |
| Time column | `rechnung_freigegeben_am` |
| Downstream object 2 | `zahlung` |
| Time column | `zahlung_ausgefuehrt_am` |
| Downstream 2 → downstream 1 key | `rechnung_id` |

### `6. Recalculate dependent values`

| Einstellung | Wert |
| --- | --- |
| Deadline stays fixed | aktiviert |
| Deadline | `skonto_frist_am` |
| Used flag | `skonto_genutzt` |
| Calculated result | `skonto_verlust_eur` |
| Base amount | `brutto_betrag` |
| Percentage | `skonto_prozent` |

## 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.

![](https://cdn-assets.productfruits.com/56286d55-5619-4aef-8d77-7ef51840e7ba)

## 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**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-expert-bundelung-und-freigabelauf)