How to uninstall SAP Product and REACH Compliance 2.0 (to get ready for SAP S/4HANA)

[harrystrauss]

Introduction

As you might know, since 31.12.2020 SAP Product and REACH Compliance 2.0 is out of maintenance. So a good time for you to switch to the successor product, or to remove the tool from your system. If you plan to use SAP S/4HANA, you must uninstall this legacy AddOn. The present blog will give some general advice and guidance to support you while uninstalling this legacy AddOn.

 

What is the tool about and what options do you have?

SAP Product and REACH Compliance 2.0 was the successor of SAP REACH Compliance 1.1 (that was used in process industry and had very limited functionality) and TechniData CfP (that was used in the discrete - or article producing - industry). So it was one software for different industries covering several use cases...

SAP Product and REACH Compliance 2.0 for discrete industry

The functionality of the tool for discrete industry: using the SAP Product Safety specification database in full range and helping customers to verify the compliance of their own products regarding ROHS, REACH SVHC, JIG, etc. All customers using this discrete industries functionality of the software tool have the possibility to migrate to the successor product SAP Product and REACH Compliance either as AddOn to SAP ECC (exact name: “Component Extension for SAP Environment, Health, and Safety Management”, formerly known as “SAP EHSM Product Compliance”) or fully embedded into SAP S/4HANA (technically, not license-wise) as solution “SAP S/4HANA for product compliance”.

The recommendation is to immediately uninstall the SAP Product and REACH Compliance 2.0 to reduce testing effort, either before migration or shortly after migration (valid for SAP ECC) to the successor product.

• What means migration?
  
  
  
  • Yes, you can migrate the outdated software to the latest version of SAP Product and REACH Compliance
  
  
  
  


• What is with your collected and maintained data?
  
  
  
  • There might be no need to use all of your legacy data
  
  
  • It is recommended to not use (migrate) old compliance structures,
    
    
    
    • but to generate only the relevant product compliance structures with the bill-of-material transfer out of the latest functionality,
    
    
    • to migrate only compliance statements that are really required and
    
    
    • where ever it applies, to re-import the relevant material data sheet (MDS) out of International Material Data System (IMDS), etc.
    
    
    
    
  
  
  
  


• What is with some key functionality that was plugged off as the Task Management, etc.?
  
  
  
  • Do you required to keep the legacy communication data or can you drop them?
  
  
  • You might switch to workflow functionality, use something different or even rebuilt task management functionality. Is this required?
  
  
  
  

 

SAP Product and REACH Compliance 2.0 for process industry

This tool had some registration and endpoint management including an interface to ECHA IUCLID that resides on a JAVA stack (mostly a separate stack to the existing SAP ECC stack). However, all data was stored at the SAP ECC backend, mainly in the specification database of SAP Product Safety.

Furthermore it offered some kind of campaign functionality to request REACH use data from the suppliers. Then to calculate the compliance of the chemical products regarding to the REACH uses (and related exposure scenarios) the supplier (or their Only Representation) had registered for the chemical substance at ECHA. These functionalities sit on the SAP ECC side.

For all these customers there is some kind of dead-end road; as the process industry functionality is not covered by any successor product. So there is no software to be migrated.

What's about the data?

At least data that was copied from the “blue channel” to the “red channel” is fully available in SAP Product Safety.

 

First conclusion

Start now with your planning for deinstallation and - where required - for migration activities.

Otherwise you will run into difficulties and get a bottleneck for your SAP S/4HANA implementation/roadmap.

In case you are not sure and/or have outsourced relevant parts of your infrastructure IT, try to book some experienced consultants ahead as they are very rare and very busy.

 

Uninstall SAP Product and REACH Compliance 2.0

Preamble

There is often some irritation at the customers SAP basis team: but the first step of the deinstallation process is to upgrade the AddOn SAP Product and REACH Compliance 2.0 to the latest support package! One of these support packages give you the ability to uninstall the AddOn. Other support packages deliver helpful reports that are recommended during deinstallation process.

Keep in mind: in former times SAP AddOns could not be de-installed from the SAP ECC system, what now is possible...

SAP Note 2298456 will guide you to the process. Maybe you handle this SAP Note as usual, give it to your SAP basis team to work on it... I expect that they come back to you, complaining that 90% of the work needs to be executed by functional and/or technical consultants.

To work on this SAP Note is a little bit time consuming; therefore I will give some guidance. This guidance is based on the version 8 of the SAP Note from 12.12.2019 and for sure none-binding.

 

Chapter 1 - change history

The easy one, change history. No activities are required.

Chapter 2 - prerequisites for uninstalling

Cross reference to SAP Note 2360310

The SAP Note 2360310 contains some relevant chapters.

Chapter one - 1751276

When installing the successor solution where the legacy solution was not yet removed, the installation process stops due to some issues while activating table ESTVP. The SAP Note 1751276 helps you to remove the not longer required append structures. Apply this as fast as possible!

Chapter two - 2298456

Reference back to the “grandparent” SAP Note 2298456. We will come back later to this.

Chapter three - 2367720

SAP Note 2367720 gives you guidance to remove legacy check functions, e.g. for identifiers. Even you are sure not using them, the recommendation is to run the report "R_EHPRC_RESTORE_CHAR_FUNC" to see if there are legacy TDAG function modules used and replace them.

Chapter four - FIBF

Use transaction FIBF to remove the function module that sits in for event CS000010. Means, after a change of a bill of material, this function module gets processed. This is very important, otherwise you get a system failure for your logistic system if the TDAG function module still gets called after removal.

Chapter five - EHSM BC

The SAP Note suggests to already run the SAP Product and REACH Compliance BC sets. However, my recommendation is to do this while actually implementing the AddOn on SAP ECC. Means, for pure deinstallation no action required here!

Cross reference to SAP Note 70228

The SAP Note 70228 is relevant for your SAP basis team. No activities for you as functional and/or technical consultant; however, make sure that the SAP basis team has confirmed that all requirements of this note are set up.

Cross reference to SAP Note 2011192

SAP Note 2011192 lists the SAP AddOns that you must remove before starting SAP S/4HANA implementation. So, no activity here for you; as we are already on the way to remove it. Just for reasons of completeness: “SAP REACH COMPLIANCE 2.0 (component TDAGBCA 200_600, note 2298456)” is listed.

Cross reference to SAP Note 2302601

Check whether you have the report “/TDAG/CPX_S4_SIMULATE_REMOVAL” in your system. In case the program does not exist, please implement SAP Note 2302601, this will add the report. We will need the report later on.

Additional to this; there are further references to SAP Notes. Two of them we already have touched, the third one is SAP Note 2300437 that supports you regarding the task management of SPRC. Please note: depending on what you want to do with the legacy data of the task management, there might be further implementation effort required.

Cross reference to SAP Note 1600792

SAP Note 1600792 is not relevant for you; however, please inform your SAP basis team as this note help out in case there are problems during transaction SAINT.

Chapter 3 - manual steps

Specific steps for Product Compliance

There is a reference to SAP Note 1489703, but in general there are no specific steps for discrete industry functionality. The few classes and characteristics that are used are still available.

Specific steps for REACH Compliance

As there is not successor for the process industry functionality, you really need to think about:

1. what functionality was used


2. what data is required


3. what functionality and data is still required

As this might be a small project within the project; I cannot give here further advice. The SAP note anyhow gives plenty of hints.

General steps for REACH Compliance and Product Compliance

Chapter a - task management

If you do not need the legacy data, just drop this sub-chapter.

If you like to keep the data, follow the given hints.

If you want to use some similar functionality as the task management has provided, then more implementation work waits for you...

Chapter b - append /TDAG/CPS_ESTVP

This append was already removed (see above), so no further activity here.

Chapter c - characteristics for material classification

In case there are check functions in, remove them. For discrete industry functionalities from my point of view, there is no data behind. For process industry you might use the data further (e.g. related to substance volume tracking functionality).

Chapter d - unschedule jobs

This sub-chapter is a good one, as often these jobs will be forgotten. So check in transaction SM37 for jobs starting with program name /TDAG/CP, TDAG/RCS, or with one of your package you were using, e.g. ZRCS. Before deactivating them, check what functionality was covered and whether you might still need some of these processes.

Chapter e - check integrations and revert them

Depending on the implemented integrations, this might be fast applied. Check the SAP Note and the IMG to find possible links. However:

• Any integration to the SAP Product Safety specification database needs to be removed
  
  
  
  • Changes at the save specification or the extended checks are very common both for process and discrete industry and needs to be checked and removed
  
  
  
  


• Material views
  
  
  
  • This is very common for discrete industry but not for process industry. So for discrete industry there are new views in the successor product that could be integrated in material views. Here the system displays compliance information of your products, etc.
  
  
  
  


• Only Representative functionality
  
  
  
  • This was solely used in process industry. Check to remove any links and in case you are using substance volume tracking, you might need some parts of the functionality.
    
    
    
    • To not give the wrong impressing: relevant parts of the Only Representation (OR) functionality were already moved from SAP Product and REACH Compliance 2.0 to SAP ECC within one of the Enhancement Packs. So not much activity is expected here.
    
    
    
    
  
  
  
  


• Data Exchange and outgoing processing
  
  
  
  • Only relevant for discrete industries as the previous compliance reports utilized the WWI (Windows Wordprocessor Integration) functionality. However now this functionality was moved completely to Adobe Interactive Forms (AIF using Adobe Document Service). Any migration here is not suggested. Rather use the (new) existing standard templates to set up new templates...
  
  
  
  


• Analytics and reporting
  
  
  
  • From my point of view (or at least my customers did not use it) this topic could be dropped in most cases...
  
  
  
  

Chapter f - remove BAdI

This is a big piece of the cake, means there is much work to be performed. There are around 33 places you need to check, whether BAdIs were used, what functionality you still need, and how to replace them.

So go ahead and remove them, but keep in mind, in case there is relevant functionality in, you need to reimplement something similar or have a rescoping workshop with business.

Chapter g - development objects for identification types

We should have touched the topic already ahead. If not: all data regarding identifiers needs to be checked whether there is some legacy check function referenced or not.

Chapter h - WWI reports

What irony: process industry functionality for SAP Product and REACH Compliance 2.0 did not use the WWI capabilities; however, most process industry customer use them in general and know them profoundly to create labels and/or safety data sheets (SDS).

Chapter i - further development objects

Just follow the guidance in the SAP Note...

Chapter j - roles cleaning

That topic is a good one. Check all roles (single or compositive) that link to one of these “/TDAG/” roles, however, more likely check the “ZPRC*” / “YPRC*” / “ZCP*”, etc. roles in your system. Removal is quite easy, but check with the business users, what functionality was behind and still might be required.

Chapter k - inbox

The campaign functionality was mainly used by process industry and partially by discrete industry. Check for these e-mail-addresses in your e-mail exchange server that push the e-mails forward to the SAP system and plug them off.

Chapter l - check TMP resources

It is a good point to check the “$TMP”  objects as well regarding links to code lines that will be removed soon. Very likely you can remove the affected “$TMP” coding, however, a chat with the developers ahead is suggested.

Chapter m -  /TDAG/CPX_S4_SIMULATE_REMOVAL

As mentioned above, now we run the report “/TDAG/CPX_S4_SIMULATE_REMOVAL”. Maybe you need to remove several user exits and several check function modules. Once the report runs without errors in simulation mode, you are ready to run the report without simulation.

Not listed in SAP Note

Now you will face the situation that there are several “Z*” or “Y*” objects in your system that should be not required any longer. Either you save the code lines and erase all these packages in transaction SE80 (fast way) or you really check each functionality before removing and getting a requirement list of still needed functionality (save but very high effort).

As mentioned, to checking each class, method, function module, report, etc. is very time consuming...

But from my point of view you should not keep orphaned packages and coding in your system.

Chapter 4 - remove SPRC with SAINT

OK, now the SAP basis team can start with the actual removal of the AddOn using transaction SAINT.

 

Conclusion

Just removing the legacy functionality is no rocket science, but needs sufficient planning ahead. Use the present guide, used the linked SAP Notes, raise questions to business users and technical consultants, etc.

However, take care performing these steps in your system (suggested is a sandbox first) and do not mess up your system and/or data as the effort to correct or rebuild data and/or system is significant higher.

In case there are open questions left, just contact the author via the SAP Community profile.