SAP GRC Process Control 3.0 sign-off lock

[former_member566284]

Is there a way to remove sign-off locks in GRC PC 3.0?

We have PC 3.0 implemented in our test system and during testing, there were Sign Offs done by a user for year 2011.

Now, the data for all orgs is frozen which are subject to sign off. I tried reloading the master data (MD) after clean up of MD in the system. The MD now can only be configured for 2012 year and hence no authorizations can be assigned at application level to the user for 2011. This means no user receives a task if a plan is created until december.

The only way I think this can be solved is by removing sign off lock for 2011 and then configure the MD for SOX regulation for 2011. Do you think there is an alternative?

We do not want to re-install and reconfigure everything obviously and hence my question to avoid this.

[claudenir_araujo]

Hi Mohammed,

The only way to revert back the sign-off process is to clean up the tables that have registered all the cases and the historical data.

You can write down a specific program to do that, as you said, this is a testing system as this shouldn't be done in production.

Please, let me know in case you need the table names and I will post that to you!

Regards

Claud.

[former_member566284]

Hi Claud,

Yes, I want to know the names of these tables as we may have to cleanup these locks on our non production systems.

Is there also a way to delete sign off workflows as I know they will exist as tasks in the user's inbox for sign offs not done?

Thanks,

Kashif

[claudenir_araujo]

Hi Kashif

These are the tables that you can write a Z.. program to delete the sign-off!

Delete from GRPCSIGNOFF.

Delete from GRPCSIGNOFF_ADD.

Delete from GRPCCLOSING.

Delete from GRPCCLOSINGBG.

Delete from GRPCCASECLONE.

Before deleting the GRPCCASECLONE table, please ensure all the related cases in this table has been deleted. If you are tring to delete all the cases, then never mind about it.

Please, be very carefull with this deletion and never do that on PROD!!

Regards,

Claud

[former_member566284]

Hi Claud,

This is great help. I shall let you know how this has worked.

Thanks,

Kashif

[former_member566284]

HI Claud,

I understand you may be from SAP. However, I had to send this to SAP formally via an OSS message as the customer wanted official confirmation from SAP. The response is below:

I notice that fewer tables have been mentioned in the message though i acknowledge this is not recommended by SAP. My question to you is what is the use of two tables (GRPCCASECLONE & GRPCSIGNOFF_ADD) that are extra to be deleted as per your suggestion here in SDN. Any reason why SAP may not have suggested these two tables. I am ensuring that we clear these only in Non-Prod systems.

By SAP message

-

---

You need to create a deletion program to do so, but this is not

Recommended by SAP.

If you still want to proceed, please follow the steps below:

Pls. Note: NOT FOR USE IN A PRODUCTIVE ENVIRONMENT

Deletion of Sign-off Tables:

Go to SE38' create one ABAP program as mentioned below - you will nee

developers key to create this. Do not create this in your productive

environment.

REPORT Z_TESTSIGNOFF.

Delete from GRPCSIGNOFF.

Delete from GRPCCLOSING.

Delete from GRPCCLOSINGBG.

Check for syntax error and activate the program and execute it.

_----

---

Thanks,

Kashif

[claudenir_araujo]

Hi Kashif

Please, let me know the message number you have opened at SAP, just for checking?!!

I am working as SAP Support engineer for GRC PC at SAP!

The two extra tables are described as below:

GRPCCASECLONE - creates some references and links for cases;

GRPCSIGNOFF_ADD - creates the information of the signoff process done in the system, if you haven't done any signoff so there will be no data in these tables!

However, before running the customized program check the table content just in case!

I hope I had helped you somehow!

Regards,

Claud Araujo

[former_member566284]

Thanks Claud for your response. The SAP OSS message number is as below:

Sign off ( 851589 / 2011 )

Thanks,

Kashif