Tutorial P2P - Loss of Discount - Working Capital

TL;DR 
Goal: Deliberately delay payments and thereby generate cases in which an existing cash-discount deadline is exceeded. 
Prerequisites: Invoice, invoice approval and payment are part of the Causal Chain. 
Result: Certain invoices are deliberately processed later, so that their payment can fall after skonto_frist_am.

The business question

Companies sometimes try to execute payments as late as possible in order to keep liquidity within the company for longer.

From a working-capital perspective, this can initially seem sensible.

At the same time, however, a conflict of objectives arises:

What happens when a deliberately delayed payment causes an existing cash-discount deadline to be missed?

For our synthetic use case, we therefore generate a relationship between:

pruefer_team

→ longer processing time

→ later payment

→ possible exceeding of the cash-discount deadline.

Desired data picture

The invoice already contains a fixed:

skonto_frist_am

In our model, this lies 14 days after the invoice was recorded.

A normal case can look like this, for example:

Rechnung

→ Rechnungsfreigabe

→ Zahlung

→ payment takes place before skonto_frist_am

With deliberately delayed processing, by contrast, the following should arise:

Rechnung

→ additional waiting time

→ Rechnungsfreigabe

→ Zahlung

→ payment lies after skonto_frist_am

1. Using a Conditional Rule

For this use case we do not need a new Special Behaviour.

Instead, we again change the process time.

Open: 04 Special Behaviour

and go to: Conditional rules (A / C / D)

Choose:

Effect: 
A · Timing (change gap)

This lets us extend an existing time gap depending on a business attribute.

2. Selecting the invoice as the starting point

As the:

Activity (gap after)

we choose: rechnung

The additional waiting time is thereby built into the process after the invoice.

At this point, the existing P2P process already has a normal processing time. For the affected cases, we now deliberately increase it.

3. Setting the condition on the checker team

Choose:

Condition – source: 
Column of this activity

Column: 
pruefer_team

Operator: 
=

Value: 
Kreditorenbuchhaltung

This links the delay to a concrete business attribute.

The statement reads:

If the invoice is processed by the team Kreditorenbuchhaltung, the subsequent process time should be extended.

4. Generating twelve days of additional waiting time

Under:

Effect on gap after the activity

choose:

+ days

and enter:

12

This adds 12 additional days to the affected cases.

The basic principle corresponds to the existing P2P demo rule for working capital: there, too, twelve additional days are generated for invoices from the Kreditorenbuchhaltung team.

Set as the:

Tag:

ZAHLUNG_BEWUSST_VERZOEGERT_WORKING_CAPITAL

Why exactly twelve days?

In our data model, the invoice has:

skonto_frist_am

with a fixed distance of 14 days from the invoice recording.

At the same time, the normal process between invoice and payment already needs several days.

If we additionally build in:

+12 Tage

many of these cases will exceed the cash-discount deadline.

This produces a deliberately generated conflict of objectives:

keeping liquidity for longer

against

losing a possible cash-discount advantage.

A fixed deadline instead of a deadline shifted along

The important point here is:

skonto_frist_am

is a deadline.

The deadline should not automatically shift back just because the internal process takes longer.

Otherwise the additional delay would not produce any economic effect.

The desired pattern is therefore:

skonto_frist_am remains unchanged

while:

zahlung_ausgefuehrt_am

moves back.

This later allows checking:

zahlung_ausgefuehrt_am > skonto_frist_am

What do we model in the Simple training?

In the Simple model, we first generate the causal time conflict:

Kreditorenbuchhaltung

→ additional 12 days

→ later payment

→ cash-discount deadline possibly exceeded.

For this, the tables already contain the relevant fields:

rechnung.skonto_frist_am

rechnung.skonto_prozent

zahlung.zahlung_ausgefuehrt_am

zahlung.skonto_genutzt

zahlung.skonto_verlust_eur

Important, however:

The normal data run does not automatically recalculate skonto_genutzt and skonto_verlust_eur after such a timing rule.

In the Simple training we therefore first look at:

Did the payment take place before or after the cash-discount deadline?

The actual financial recalculation follows later in Expert Mode.

What is added in Expert Mode?

In the Expert part, we connect this principle with a real:

Capacity Bottleneck

and:

Backlog

There, the delay no longer arises merely from a fixed defined rule, but from limited process capacity.

The additional delay is then propagated downstream through to the payment.

After that, the Smart Data Forge can actually redetermine:

skonto_genutzt

and:

skonto_verlust_eur

when the shifted payment lies past the fixed deadline.

This later extends the causal chain to:

Kapazitätsengpass

→ Backlog

→ longer cycle time

→ delayed payment

→ lost cash discount.

In the Simple model we already lay the business groundwork for this.

The finished rule

What should I later see in Noreja?

Cases with:

pruefer_team = Kreditorenbuchhaltung

should exhibit a significantly longer cycle time between invoice and payment.

In addition, we can check:

Which payments lie after skonto_frist_am?

Which teams or process characteristics explain delayed payments?

How strongly do cases with and without a working-capital delay differ?

Later, the financial question can also be derived from this:

How much cash discount is lost through process delays?

With this, we connect a process cause with a possible financial effect for the first time.

Difference from poor supplier performance

Both use cases use a Conditional Rule, but pursue different business hypotheses.

Poor supplier performance

Lieferant

→ process takes longer.

Working Capital

internal checker team

→ payment is deliberately delayed

→ financial deadline can be exceeded.

This makes it visible that longer cycle times can arise from both external and internal causes.

Common mistakes / things to watch out for

Use + days and not × factor. 
We want to add twelve days deliberately.

Do not shift skonto_frist_am along. 
The deadline must stay fixed so that a delayed payment actually becomes recognizable.

Distinguish Simple and Expert. 
In the Simple model we generate the delay and the cash-discount risk. The automatic calculation of the actual cash-discount loss follows later in the Expert part.

Result

With this, our Simple data set now contains all the intended synthetic use cases:

Maverick Buying 
→ an intended approval path is bypassed.

Poor supplier performance 
→ a supplier extends process times.

Order change / rework 
→ an order is processed after the fact.

Wrong Order 
→ order and approval lie in the wrong temporal sequence.

Open processes 
→ cases deliberately end at various points in the process.

Working Capital / cash-discount risk 
→ internal decisions delay the payment and can jeopardize financial deadlines.

With this, the Simple part of the demo training is complete.

Next step

Save this state as:

Config 2 – Simple

In the next section we switch to:

Mode: Expert

and extend the P2P model with different procurement paths, capacity bottlenecks, backlogs, delay propagation and the actual calculation of cash-discount losses.

Next: Tutorial P2P Expert XOR -  different procurement paths