Tutorial P2P - Skontoverlust - Working Capital

TL;DR
Ziel: Zahlungen gezielt verzögern und dadurch Cases erzeugen, bei denen eine vorhandene Skontofrist überschritten wird.
Voraussetzungen: Rechnung, Rechnungsfreigabe und Zahlung sind Bestandteil der Causal Chain.
Ergebnis: Bestimmte Rechnungen werden bewusst später verarbeitet, sodass ihre Zahlung nach skonto_frist_am liegen kann.

Fachliche Fragestellung

Unternehmen versuchen teilweise, Zahlungen möglichst spät auszuführen, um Liquidität länger im Unternehmen zu halten.

Das kann aus Working-Capital-Sicht zunächst sinnvoll erscheinen.

Gleichzeitig entsteht jedoch ein Zielkonflikt:

Was passiert, wenn eine bewusst verzögerte Zahlung dazu führt, dass eine vorhandene Skontofrist verpasst wird?

Für unseren synthetischen Use Case erzeugen wir deshalb einen Zusammenhang zwischen:

pruefer_team

→ längerer Bearbeitungszeit

→ späterer Zahlung

→ möglicher Überschreitung der Skontofrist.

Gewünschtes Datenbild

Die Rechnung enthält bereits eine feste:

skonto_frist_am

In unserem Modell liegt diese 14 Tage nach Rechnungserfassung.

Ein normaler Case kann beispielsweise so aussehen:

Rechnung

→ Rechnungsfreigabe

→ Zahlung

→ Zahlung erfolgt noch vor skonto_frist_am

Bei einer bewusst verzögerten Bearbeitung soll dagegen entstehen:

Rechnung

→ zusätzliche Wartezeit

→ Rechnungsfreigabe

→ Zahlung

→ Zahlung liegt nach skonto_frist_am

1. Conditional Rule verwenden

Für diesen Use Case benötigen wir kein neues Special Behaviour.

Wir verändern stattdessen wieder die Prozesszeit.

Öffne: 04 Special Behaviour

und gehe zu: Conditional rules (A / C / D)

Wähle:

Effect:
A · Timing (change gap)

Damit können wir einen bestehenden Zeitabstand abhängig von einem fachlichen Attribut verlängern.

2. Rechnung als Ausgangspunkt auswählen

Als:

Activity (gap after)

wählen wir: rechnung

Die zusätzliche Wartezeit wird damit nach der Rechnung in den Prozess eingebaut.

Der bestehende P2P-Prozess besitzt an dieser Stelle bereits eine normale Bearbeitungszeit. Für die betroffenen Cases erhöhen wir diese nun gezielt.

3. Bedingung auf das Prüfer-Team setzen

Wähle:

Condition – source:
Column of this activity

Column:
pruefer_team

Operator:
=

Value:
Kreditorenbuchhaltung

Damit verbinden wir die Verzögerung mit einem konkreten fachlichen Attribut.

Die Aussage lautet:

Wenn die Rechnung vom Team Kreditorenbuchhaltung bearbeitet wird, soll sich die nachfolgende Prozesszeit verlängern.

4. Zwölf Tage zusätzliche Wartezeit erzeugen

Unter:

Effect on gap after the activity

wähle:

+ days

und trage ein:

12

Damit werden den betroffenen Cases 12 zusätzliche Tage hinzugefügt.

Das Grundprinzip entspricht der vorhandenen P2P-Demo-Regel für Working Capital: Auch dort werden für Rechnungen des Teams Kreditorenbuchhaltung zwölf zusätzliche Tage erzeugt.

Setze als:

Tag:

ZAHLUNG_BEWUSST_VERZOEGERT_WORKING_CAPITAL

Warum gerade zwölf Tage?

Die Rechnung besitzt in unserem Datenmodell:

skonto_frist_am

mit einem festen Abstand von 14 Tagen zur Rechnungserfassung.

Gleichzeitig benötigt der normale Prozess zwischen Rechnung und Zahlung bereits mehrere Tage.

Wenn wir zusätzlich:

+12 Tage

einbauen, werden viele dieser Cases die Skontofrist überschreiten.

Damit entsteht ein bewusst erzeugter Zielkonflikt:

Liquidität länger halten

gegen

möglichen Skontovorteil verlieren.

Feste Deadline statt mitverschobener Frist

Wichtig ist dabei:

skonto_frist_am

ist eine Deadline.

Die Frist soll sich nicht automatisch nach hinten verschieben, nur weil der interne Prozess länger dauert.

Sonst würde die zusätzliche Verzögerung keinen wirtschaftlichen Effekt erzeugen.

Das gewünschte Muster lautet deshalb:

skonto_frist_am bleibt unverändert

während:

zahlung_ausgefuehrt_am

nach hinten wandert.

Dadurch kann später geprüft werden:

zahlung_ausgefuehrt_am > skonto_frist_am

Was modellieren wir im Simple-Training?

Im Simple-Modell erzeugen wir zunächst den kausalen Zeitkonflikt:

Kreditorenbuchhaltung

→ zusätzliche 12 Tage

→ spätere Zahlung

→ Skontofrist möglicherweise überschritten.

Die Tabellen enthalten dafür bereits die relevanten Felder:

rechnung.skonto_frist_am

rechnung.skonto_prozent

zahlung.zahlung_ausgefuehrt_am

zahlung.skonto_genutzt

zahlung.skonto_verlust_eur

Wichtig ist jedoch:

Der normale Datenlauf berechnet skonto_genutzt und skonto_verlust_eur nach einer solchen Timing-Regel nicht automatisch neu.

Im Simple-Training betrachten wir deshalb zunächst:

Ist die Zahlung vor oder nach der Skontofrist erfolgt?

Die tatsächliche finanzielle Neuberechnung folgt später im Expert Mode.

Was kommt im Expert Mode hinzu?

Im Expert-Teil verbinden wir dieses Prinzip mit einem echten:

Capacity Bottleneck

und:

Backlog

Dort entsteht die Verzögerung nicht mehr nur durch eine fest definierte Regel, sondern durch begrenzte Prozesskapazität.

Die zusätzliche Verzögerung wird anschließend downstream bis zur Zahlung propagiert.

Danach kann die Smart Data Forge tatsächlich neu bestimmen:

skonto_genutzt

und:

skonto_verlust_eur

wenn die verschobene Zahlung hinter der festen Deadline liegt.

Damit erweitert sich die Kausalkette später zu:

Kapazitätsengpass

→ Backlog

→ längere Durchlaufzeit

→ verspätete Zahlung

→ verlorenes Skonto.

Im Simple-Modell legen wir dafür bereits die fachliche Grundlage.

Die fertige Regel

Was sollte ich später in Noreja sehen?

Cases mit:

pruefer_team = Kreditorenbuchhaltung

sollten eine deutlich längere Durchlaufzeit zwischen Rechnung und Zahlung aufweisen.

Zusätzlich können wir prüfen:

Welche Zahlungen liegen nach skonto_frist_am?

Welche Teams oder Prozessmerkmale erklären verspätete Zahlungen?

Wie stark unterscheiden sich Cases mit und ohne Working-Capital-Verzögerung?

Später kann daraus auch die finanzielle Fragestellung abgeleitet werden:

Wie viel Skonto geht durch Prozessverzögerungen verloren?

Damit verbinden wir erstmals eine Prozessursache mit einem möglichen finanziellen Effekt.

Unterschied zu schlechter Lieferantenperformance

Beide Use Cases verwenden eine Conditional Rule, verfolgen aber unterschiedliche fachliche Hypothesen.

Schlechte Lieferantenperformance

Lieferant

→ Prozess dauert länger.

Working Capital

internes Prüfer-Team

→ Zahlung wird bewusst verzögert

→ finanzielle Deadline kann überschritten werden.

Damit wird sichtbar, dass längere Durchlaufzeiten sowohl durch externe als auch durch interne Ursachen entstehen können.

Typische Fehler / darauf achten

+ days und nicht × factor verwenden.
Wir möchten gezielt zwölf Tage hinzufügen.

skonto_frist_am nicht mitverschieben.
Die Deadline muss fest bleiben, damit eine verspätete Zahlung tatsächlich erkennbar wird.

Simple und Expert unterscheiden.
Im Simple-Modell erzeugen wir die Verzögerung und das Skontorisiko. Die automatische Berechnung des tatsächlichen Skontoverlusts erfolgt später im Expert-Teil.

Ergebnis

Damit enthält unser Simple-Datensatz nun alle vorgesehenen synthetischen Use Cases:

Maverick Buying
→ ein vorgesehener Freigabeweg wird umgangen.

Schlechte Lieferantenperformance
→ ein Lieferant verlängert Prozesszeiten.

Bestelländerung / Rework
→ eine Bestellung wird nachträglich bearbeitet.

Wrong Order
→ Bestellung und Freigabe liegen in der falschen zeitlichen Reihenfolge.

Offene Prozesse
→ Cases enden gezielt an unterschiedlichen Prozessstellen.

Working Capital / Skontorisiko
→ interne Entscheidungen verzögern die Zahlung und können finanzielle Fristen gefährden.

Damit ist der Simple-Teil des Demo-Trainings abgeschlossen.

Nächster Schritt

Speichere diesen Stand als:

Config 2 – Simple

Im nächsten Abschnitt wechseln wir auf:

Mode: Expert

und erweitern das P2P-Modell um unterschiedliche Beschaffungspfade, Kapazitätsengpässe, Backlogs, Delay Propagation und die tatsächliche Berechnung von Skontoverlusten.

Weiter: Tutorial P2P Expert XOR -  unterschiedliche Beschaffungswege