Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

Hi everyone,

starting 7.10 the new Request for Change (RfC) was introduced. This RfC inherits from the CRM standard ITCH (CRM Request for Change) but is widely enhanced.

It uses the approval procedure known from the ITCH in CRM standard.

But there are more possibilities than in CRM standard! The CRM standard approval procedure can be used only once. The ChaRM RfC instead allows you to extend the scope and create further change documents, meaning add further scope items. This can be done if a RfC has created already change documents.

But the new change documents which will be created when the scope is extended have to be approved as we implemented an initialization of an already closed approval procedure. This is done via ChaRM action 'APP_PROC_INI'.

Check the ChaRM action customizing for that:

There are further special cases where we had to enhance the approval procedure functions. Imagine, a RfC is in status 'To be approved' and the last approver approves the RfC scope the ChaRM Framework is run through to set the status 'Approved'. But a consistency Check is customized to reset the user status back and not fulifilled. In this case, the approval procedure has to be opened up, again.

This is be done by ChaRM action  APP_PROC_TBA (where TBA is short for 'To be Approved').

The opening-up of the approval procedure is hard-coded in the reset but customers may use this ChaRM action if needed. It just opens up the last approver step(s), setting the last status of the approval steps when the status 'To be Approved' was reached.

The logic of the approval procedure can be quite complicated when the scope is extended. Are there already change documents created, is it approved or rejected...when to set which user status.

The IMG activity 'Set Up Process-Dependent Status Control' controls which status is set.

The last on 'PRE_APPR' is used for the normal change for the Preliminary Import process. to define which status to set if the Preliminary Import is approved.

Last but not least, I created an user status flow of the RfC, including an overview of the ChaRM Framework and the Approval Procedure logic.

I hope that helps to get some sort of overview of the three players status flow, approval procedure and ChaRM Framework.