Skip to Content
Personal Insights
Author's profile photo Andreas Breitrueck

➡️ CDHDR&POS ⬅️ – demon to some – angel to others

Many of you focusing on value creation through process mining in SAP systems touching 2 data base tables:

  • CDHDR – reads ‘SeeDeeHeader’
  • CDPOS – reads ‘SeeDeePos”

These tables store information about data that was changed. The header Table tells you the object and the time of change, the Pos table keeps track of the initial value, and the changed to value.

The concept is easily understood by looking into an example :

  • You want to change the MRP Type of Material A456 in Plant 0815 from PD to ND
    • (your MRP Controller complained about a recurring exception message from the MRP run that the material status does not allow for planning ( he said he was using SAP SIGNAVIO Process Insights – Process Performance Indicator KPMRP00260 ‘Combinations with MRP list exceptions during rescheduling)
  • You make the change in MM02
    • in the background, the SAP System updates the corresponding field on Data Base table MARC, and inserts two entries, one into CDHDR and the other into CDPOS
  • You can see this by getting back to the material master, displaying the changes to the material.

All good, so we did a change to some active plant specific material master data, and we left a trace of the change on the change document tables.


This is relatively straight forward, and pretty interesting as you may want to understand the sequence of changes



So, analysing Material Master changes is super straight forward 😎.

😬 But assessing other type of changes e.g. in the area of Purchase Orders can lead to difficult conclusions, and sometimes to complete misinterpretations.

Here is a little snapshot on PO Changes


While what you see makes sense, it is pretty misleading : So here is what you need to keep in mind when assessing change patterns on POs or PRs

  • One CDHDR – CDPOS tuple does NOT necessarily represent an isolated change activity🥴
  • One manual change to a PO can lead to a cascade of changes 😶‍🌫️

In other words, if you measure 100.000 Changes to POs in one month (by counting CDHDR entries for object type Purchase Orders in a time frame) – the amount of manual activities may be as small as 1% of it only.

So this is why I recommend to review any analysis that is based on CDHDR and CDPOS entries – as sometimes your ‘discovered gold’ may slip through your hands. SAP PROCESS INSIGHTS helps you doing this, since it provides a powerful set of additional information describing the change, and if you are into process mining, you may observe the cycle times between the different change events – a cascade of automated changes will show cycle times of almost 0 😉


Any thoughts, comments, complaints, tears, conclusions, observations? I would love to hear back from you, either directly through this post, or you can reach out to me directly.

Happy year end !

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Thomas Bodenmueller-Dodek
      Thomas Bodenmueller-Dodek

      Hi Andreas,

      nice read and valuable guidelines for the interpretation of PO changes - so "not all that glitters is gold" (no clue if the native speakers would use that saying 😉




      Author's profile photo Andreas Breitrueck
      Andreas Breitrueck
      Blog Post Author

      but your German saying nails it well. Many thanks - btw - the same applies for changes to PRs 🤘

      Author's profile photo Gia-Thi Nguyen
      Gia-Thi Nguyen

      Dear Andy,


      lots of tears - both pain and joy that finally someone addresses the bitter pill to swallow -> CDPOS and CDHDR can be lots of fun and cause lots of unnecessary work to explain.


      In the below screenshot you can see how the "pro's" and the "beginners" differ.

      Some would love to count the insights they have seen from all those "non-conformant" manual activities. Yes, with processing time 0 as you mentioned. So what? Exactly - nothing.

      We need to go to the root cause of the change that triggered all the other automatic changes (which is a good sign). Of course, if you are solely driven by metrics of "HOW MANY MANUAL TOUCHES" instead of "HOW MANY MANUAL TOUCHES DO ACTUALLY HAVE A NEGATIVE IMPACT" (e.g. on cycle time, etc.), things can and will go awry.


      To simplify what you already outlined so well:

      Let's focus on Quality instead of Quantity

      Let's focus on Causality instead of Correlation.

      Let's avoid quantitative correlation just for nice dashboards and powerpoints to impress. Let's not forget, there are actual people behind the scenes who do open VA02, MM02, ME22N, etc. It would be sad to make their challenging processes even more challenging!




      One change leads to many changes - so what?!

      Author's profile photo Andreas Breitrueck
      Andreas Breitrueck
      Blog Post Author

      Love it Thi !

      Causality instead of Correlation - this describes the observable patterns well : If (1) is changed, (2), (3) and (4) will be changed as well - so the change of (1) induces correlated changes on the others.

      With respect to master data changes, it can be interesting focusing on some particular, manually triggered changes such as : WEBAZ (Wareneingangsbearbeitungszeit) or 'Goods Receipt Time' - you will find organisations 'optimising' this setting, whereas they do not optimise other settings such as

      • Planned Delivery Time

      I have seen occasions where humans spend time on altering the WEBAZ from 1 day to 2 day, whereas the PLIFZ is set to 30 ( remember the week misconception) - but actual delivery times are e.g. 45 days.

      So people spend energy and effort to optimise a setting, that literally has absolutely no effect since other, more dominant values are way off.



      Author's profile photo Dietmar Splitt
      Dietmar Splitt

      There is still the misconception that the insights are in the raw data,
      but instead it is knowing the context and how to interpret all the data in the tables.

      There is no 'MasterData' and no 'PO' in the Database, it is always a combination of several
      tables/joins with a lot of filtering to prepare the informations to get the department's view
      on the data and finally to obtain some insights.

      Author's profile photo Andreas Breitrueck
      Andreas Breitrueck
      Blog Post Author

      context is king Dietmar, fully agree.

      But in case of material master, the data is structured pretty straight forward, you can do magic with MARA and MARC.

      Author's profile photo Basawaraj Patil
      Basawaraj Patil

      Nice read and thanks for providing insight.