---
title: "Tutorial P2P - Error Pattern: Order Before Final Approval - Wrong Order"
url: "https://docs.noreja.com/en/article/p2p-tutorial-error-pattern-order-before-final-approval-wrong-order"
language: "en"
last_updated: "2026-09-22T10:50:03.891Z"
---

# Tutorial P2P - Error Pattern: Order Before Final Approval - Wrong Order

> **TL;DR**   
> **Goal:** Generate cases in which an order lies, in time, before a required approval.   
> **Prerequisites:** The approval structure with `DUAL` and `DIRECT` is in place.   
> **Result:** In a portion of the approval-required cases, `bestellung` lies, in time, before `freigabe_b`.

## The business question

In the regular procurement process, an approval-required order should only be created after the necessary approvals have been given.

The expected sequence is:

`Bestellanforderung`

→ `Freigabe A / Freigabe B`

→ `Bestellung`

A possible compliance deviation, by contrast, is:

`Bestellanforderung`

→ `Bestellung`

→ `Freigabe B`

The approval is not completely missing here. It merely happens **too late**.

This is exactly where this use case differs from maverick buying.

## Maverick buying vs. wrong order

With **maverick buying**, an intended approval path is bypassed.

With **wrong order**, the approval still takes place – but in the wrong temporal sequence.

**Maverick Buying**

`Bestellanforderung → Bestellung`

Approval is skipped.

**Wrong Order**

`Bestellanforderung → Bestellung → Freigabe`

Approval is present, but happens only after the order.

This generates a different kind of compliance problem.

## 1\. Creating a wrong-order rule

Open:

`04 Special Behaviour`

and add a new `Add deviation rule`.

Choose:

**Type:**   
`Wrong order (swap two slots)`

The Smart Data Forge uses `Wrong order` to swap the timestamps of two process slots with one another.

## 2\. Selecting the two process steps

Choose:

**Slot A:**   
`freigabe_b`

and:

**Swap with:**   
`bestellung`

This defines which two process events are to swap their temporal position.

In the normal case the following applies:

`freigabe_b`

→ `bestellung`

In the wrong-order case the following arises:

`bestellung`

→ `freigabe_b`

![](https://cdn-assets.productfruits.com/29da7638-f8f1-441f-97ca-1a4459f1802d)

## What is actually changed in the process?

`Wrong order` does **not change the relational structure** of the data set.

Foreign keys, table relationships and the actual `Causal Chain` remain in place.

Instead, the timestamps of the two selected slots are shifted in time after the normal data generation. The engine applies such deliberately generated wrong-order anomalies only after the regular causal timestamp generation.

This deliberately gives us data in which:

**the relationship still exists in business terms, but the temporal sequence is no longer plausible.**

It is exactly such cases that are particularly interesting for process mining.

## 3\. Applying wrong order only to approval-required cases

Here we have to take into account a particularity of our P2P model.

`freigabe_b` exists only on the:

`DUAL`

path.

In a regular:

`DIRECT`

case there is no `freigabe_b`.

We therefore want to avoid a DIRECT case being selected as wrong order, even though no second approval is intended there at all.

For this we first set, on the wrong-order rule:

**Probability (%):** `5`

![](https://cdn-assets.productfruits.com/49aa8db0-b78e-4861-932d-ff3ec1edb5e0)

This way the following applies:

> If a `freigabe_b` exists for the case, there is a probability of 5% that its temporal sequence with the order is swapped.

## 5\. Flagging the deviation

On the wrong-order rule, set as the:

**Tag:**

`BESTELLUNG_VOR_FINALER_FREIGABE`

## The finished configuration

### Wrong-order rule

| Setting | Value |
| --- | --- |
| Type | `Wrong order` |
| Slot A | `freigabe_b` |
| Swap with | `bestellung` |
| Probability | `5 %` |
| Tag | `BESTELLUNG_VOR_FINALER_FREIGABE` |

## What changes in the data set?

Without deviation:

`Bestellanforderung`

→ `Freigabe A / B`

→ `Bestellung`

With wrong order:

`Bestellanforderung`

→ `Bestellung`

→ `Freigabe B`

The important point is:

The approval was **not removed**.

It is still present, but lies, in time, after the order.

This deliberately generates a case in which the process structure and the time logic no longer match one another.

## What should I later see in Noreja?

In Noreja, individual approval-required cases should become visible in which the order was already placed before the required approval.

Possible analysis questions are:

**How many orders were created before the approval was completed?**

**Which requesters, product groups or order values occur particularly often in these cases?**

**What effects does the wrong sequence have on the rest of the process?**

Particularly interesting here is the comparison with maverick buying:

**Maverick Buying:** approval is missing.

**Wrong Order:** approval exists, but comes too late.

This allows two process anomalies that appear similar to be cleanly separated from one another in business terms.

## Common mistakes / things to watch out for

**Do not confuse wrong order with overjump.**   
We do not want to remove the approval, but merely change its temporal position.

**Only consider approval-required cases.**   
A `DIRECT` case without `freigabe_b` is not a wrong-order case.

**The relational structure remains in place.**   
`Wrong order` manipulates the timestamps – not the foreign keys or the causal chain.

## Result

Our data set now additionally contains a genuine temporal process deviation:

`erforderliche Freigabe`

→ should take place before the order

becomes, in selected cases:

`Bestellung`

→ `Freigabe`

With this, alongside missing activities, performance problems and rework, we now also have a **sequence violation** in the synthetic P2P data set.

## Next step

Next, we model processes that do begin regularly but **do not run through to the end**:

**Process abort / open processes**

For this we use the `Abort` behaviour and deliberately have cases end after various process steps.

**Next:** [**Purchase-to-Pay Error Pattern Process Abort or Open Processes**](https://docs.noreja.com/en/article/p2p-tutorial-error-patterns-process-termination)