Price Change: how to do this right in your code


In our O2C Projects we had a big issue concerning Price Change.
Why, you may say?
The reason for that was that in the standard Celonis code the field Net Value was used as an indicator. This gave us many false positives every Credit Block touches this field for example.
So what is the right approach? Talk with the SD people and you find out :grinning:!
It is quite simple: in SAP price are always changed using “conditions”. For exmaple a condition can be Rabatte of x % or Manual Price. So the crucial part is to go into the CDPOS and Field KONVC and look for your condition. Within the same Changenumber also the Netvalue will be changed. In case of Header conditions you will need to go to the CDHDR.
The beauty of it is that you can see which Price condition is being used; which gives you a lot of information.
And now we understand where the Diference in Net Value really are and the source of it.
We have one “Cockpit” only covering this subject.

As a further result we also ahd a look which SO started with a manual condition (Table KONV.KSCHL) We created an own activity “Create SO (Manual Price)”. This is important since you then know that the pricelist are not there or incorrect or… A great way to analyse this topic further.

What is your experience concerning this topic?


Dear Hans,

continuing on our “dialogue” over the Celonis Community (we seem to be very active haha), again great post.

Here is how we had to think about Change Price:

There are three main mathematical scenarios:

  1. A becomes B
  2. A becomes 0
  3. 0 becomes A

Then there are many more sub-scenarios
1.A becomes B

  • a. B is bigger than A
  • b. B is smaller than A

and of course below that are many different sub-sub-scenarios, here for 1.a) :

  • B is a multiple integer (e.g. 12 times) bigger than A (e.g. the lovely Piece and Pack unit of measurement topic)
  • B is a very stable multiple factor (around 1.12-1.15 bigger than A (e.g. the lovely currency exchange factor topic)

… the list goes on …

But we know:
100% of what we know
50-60% of how, because we have a great community with domain experience
but … 0% of the why… but that’s what we do: talk to our colleagues, analyze together, change and avoid the topics altogether where possible, or have it at least ringfenced.
The performance is really bad when dealing with joins of KONV (3 bn entries for one system alone, we have many systems) with other mega tables like CDPOS, etc.

But in 4.5 we will revisit this topic.

Great contribution, as always!


Dear Thi,

Thanks for your great post.
I have one difficulty: you talk about “Billions” of entries and joins.
in our case we have 100 Billion entries in the CDPOS on the SAP ERP side (on HANA as well).
We of course only extract from the SAP ERP CDPOS only the entries relevant for O2C and P2P. You end up on the SAP BI side with less then 0.2 Billion entries.
This is no problem for our Scripts running in the SAP HANA Studio (in SAP BI) filling the event table. (Certainly when you take into account that we only look max. 15 months back); meaning we even use much less entries)
Below a part of the script (without currency conversion : Value from -> to; Change numbers etc.):

WHEN RIGHT(CDPOS_COND.TABKEY,4) LIKE ‘ZH%’ THEN ‘Sales: Manual Header Discount [ZH*]’
WHEN RIGHT(CDPOS_COND.TABKEY,4) LIKE ‘ZI%’ THEN ‘Sales: Manual Item Discount [ZI*]’
WHEN RIGHT(CDPOS_COND.TABKEY,4) = ‘ZPR0’ THEN ‘Sales: Change Price [ZPR0]’
ELSE ‘Sales: Change Price [else]’

As you can imagine we have much more then 100 Price Conditions but through the naming convention on the SAP side:

List item

ZH = Price Change on Header level
ZI = Price Change on Item level
ZPR0 = manual Price
It was for us very easy to make these differences.
An the best part: it gives you enormous insights on the topic “Price Change”.
We have setup nice tables and Graphs to let the business understand better were those conditions are used and find possible root causes for that…

Have :grinning:!


That’s really nice. Definitely will have a deeper look!