on 05-30-2021 6:26 PM
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 🙂
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
11 | |
8 | |
7 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.