Explosion of type "E" CDPOS data for ADRESSE changes

[former_member771549]

Hello,

In our ECC, EWM, TM and GTS systems we have noticed that when a ADRESSE change is sent via RFC from one environment to another in addition to the legitimate CDHDR and CDPOS data we will get multiple type 'E' (delete individual field) rows in CDPOS. I have been assured by both our developers and our DBA that there is no way to delete an individual field in ECC with our data base management software.

This first came to our attention with VIM from OpenText. OpenText did included a correction in their SP10 that stopped the creation of new type 'E' CDPOS for VIM change but (at least so far) have not shared a solution for removing the over 2 BILLION rows of CDPOS data that their software error added to our ECC data base.

Since the type 'E' records are included with a legitimate change header and other change detail that need to be kept the proposed solutions (by both SAP support and OpenText support) of using data archiving (CHANGEDOCU) or RSCDOK99 Change log purge are unacceptable solutions.

In addition to the over 2 billion rows of CDPOS we have now uncovered just under a billion type 'E' change detail related to ADRESSE. Once again these records and included with legitimate change headers and change details so the SAP proposal of 'Archive or 'purge' is not an acceptable solution. SAP "support" also offered that the VIM related changes were actual deletions of entire rows rather than individual fields and when I pushed back with two comments: But the rows were not actually deleted, and why would it be necessary to provide multiple type 'E' changes for different fields in the same row if that is what truly happened? That is when SAP support determined that it was time to toss this to OpenText support where the problem still sits waiting for a SOLUTION multiple weeks later.

Are you an ECC instance with very large CDPOS data? Please check for type 'E' details in either ADRESSE or in /OPT* change types? If you find excessive records please report the issue to SAP.

Have a great day 🙂

[former_member771549]

Hello,

I have just been informed that OpenText will start work for a Z program to remove the VIM related type 'E' CDPOS data. For 3M this will permit us to remove 2 billion rows in CDPOS for change detail that was incorrectly added to the table.

Now if SAP would consider a similar program for the billions of rows related to address changes that created the incorrect type 'E' CDPOS data for change type ADRESSE.

Have a great day 🙂

Kirby

[maulik]

How long did it take to delete the 2 Billion records?

[former_member771549]

I have been working with SAP on this issue, but I am not satisfied with the answers that I have been receiving from SAP.

I believe that when a field such as ADR2-TELNR_LONG was updated from ' 612-216-5155' to '1-612-216-5155' there would be a single detail line in CDPOS and it would indicate an update type 'U' and have a value in both the old value and in the new value fields.

It now appears that SAP has chosen to document the change log by using a detail line for ADR2-KEY showing the action code 'I'. Which accurately reflects the SQL activity. Then in addition, however many fields in ADR2 that are configured for detail change logging would also include a type 'E' detail line with the OLD value for that field.

Table ADR2 has seventeen fields and at 3M 10 fields are configured for detail logging, however the ADR2-TELNR is not one of the fields. So if a TENR_LONG value is changed, rather than a single line of change detail indicating both the old value and the new value of just the one changed field, there are eleven detail lines showing the insert of the key and ten lines of type 'E' showing the 'old' values. Of course, in this specific example none of the eleven detail lines actually show the single field that was changed and for each of the ten lines showing type 'E' the "old value" is equal to the "new value".

Why would every change to ADR2 show the detail of the old values for ten fields even if those values were not actually changed?

[former_member771549]

Additional information, SAP support has identified a problem with a Vistex BADI, /IRM/BADI_GAM_UPDATE this BADI was not modified by 3M, but is the original code from Vistex, a certified SAP partner. Unfortunately for 3M this BADI results in the Address changes with the massive amount of type 'E' changes that never happened being shared out to other SAP instances for TM, EWM and GTS. So not only is this BADI which is only in ECC (if you have Vistex) but also has resulted in over a billion rows of detail in our other SAP instances. While we have proven that we can shut off this BADI, it still leaves us with a significant effort to clean up the change logs in four SAP environments.

[former_member771549 · Accepted solution]

The deletion of the 2 billion records took over ten days, running 24 by 7. OpenText had provided a Z program based on the standard SAP program RSARCHD, but the performance was so slow that we didn't feel that we could use that solution. After working with a 3M developer we had improved the performance to the point where our BW replication was getting over run with the CDPOS deletions. We then had to limit each execution to 200,000 deletions of CDPOS data which ran anywhere from ten seconds to two minutes depending on the system load. Then the Redwood scheduler would give the ECC system a three minute breather before submitting the next execution of the 3M modified solution.

[former_member771549]

Hello, Further information from SAP. Tracking address changes with type 'E' and type 'J' in S/4 HANA is an EU tax audit requirement and if you are an international company still on ERP and change settings in transactions SE11 and SCDO in ERP to suppress these changes you run the risk of not capturing these changes once you go to S/4 HANA.

Have a great day 🙂

[former_member771549]

Hello,

In addition to the (since corrected by OpenText) error in Vendor Invoice Management package, SAP has identified a second problem with add-on software. Vistex BAPI IRM/BADI_GAM_UPDATE has an error that resulted in any address change to a single field inserting over 50 detail lines in CDPOS rather that the then expected two lines of change detail.

Hopefully this information might save some other SAP add on customer the frustration that 3M has encountered with our SAP change logs.

Have a great day 🙂