Accepted Solutions (0)
Answers (4)
Below, you are going to find the steps that after some research here and there and with the help of some colleagues, we were able to configure and successfully test. This is a more extended approach than the one found in the 7.1 upgrade guide release 1.1 of Jan 2012. From our perspective the guide assumes many things and we thought it may be useful for some of the population to get more chopped steps to make the topic better able to be digested. You will be the judge. We have the best intention to make it happen.
If you cannot read the attached pictures, we are more than welcome to send you the original document. Please send me an e-mail. Juan.
In principle you can live with the approval process as is, but if you want to know how to build more complicated scenarios, with 2+ approvals and also forcing that the approval steps are mandatory to be in sequence, the information below will tell you how.
Scenario produced and tested on: SolMan 7.1 SP06
We are going to use 2 pieces of IMG: SPRO > Ref IMG > SAP SolMan > Capabilities > Change Management > Standard Configuration > Transaction Types > Approval Settings:
Piece 1: All the configuration is done in Define Approval Settings
Piece 2: The assignment of that configuration to your Transaction Type in Assign Approval Determination Procedures to Transaction Types.
Let’s get started.
Piece 1. Define Approval Settings.
First of all, for the following steps, it is mandatory you perform the sequentially from top to bottom.
Step 1. Create the approval procedure.
Double-click on Define Approval Procedure and select New Entries. Populate your new entry and save it.
Note 0: Always, before continuing to the next folder, save your changes as you progress. It is not obvious, as you may think you can perform all the configuration in all the folders and save at the end, but CRM configuration was not designed to work like that.
Note 1: As mentioned in many other related configuration documents, the Approval Status used is IT000003. This is a standard one with 3 approval status: Approve, Rejected, Not Relevant. If the 3 statuses are not sufficient for you, consider creating a new one approval status (not documented in the present trace).
Step 2. Define when the approval procedure is to be locked out (not selectable anymore). It seems logic when you create a Request for Change (R4C) , that there is a moment in which due to the amount of data entered and the workflows already in place, you cannot change the approval procedure any more.
In order to configure this step, select the entry you just created and double-click on Lock Approval Procedures. Create a new entry as displayed below and select from the 2 options when the R4C will be locked or not changeable anymore.
As you see there are not many options to choose from now.
Honestly, option 0 seems out of the loop here. We do not know the reason and we are going to place it in basic terms. If you have a requester opening an R4C, it is very unlikely that person knows what approval procedure to use right at the beginning. It may be more a task for the next person on the workflow process to decide, either the change manager or a CAB representative. That person or to put it in exact terms, that Business Partner (BP) adds sufficient data to the R4C to get it approved. Once that BP adds enough information and selects the approval procedure, option 1 should take place.
There could be companies where the 1st BP who creates the R4C has sufficient information to lock the approval at the very first save, but we have not seen that case in our experience.
There are ways to add more Approval Locking Procedures, but we are not focusing on that in this trace.
Once you have your entry entered, save your changes and proceed to
Step 3: Define Approval Steps. Just double-click the option from the menu and create the new entries. For our case we created 2 steps.
Note 2: One important thing to understand at this point in time, when you double-click on each of the folders of this transaction is the fact that you get access to see all that has been created for all the approval procedures that exist. That is very confusing, because you would have expect, e.g., that when you had selected an entry like your newly created approval procedure, if then you double-click on Define Approval Steps, an empty table would be displayed for you to create new entries, but instead of that you get access to all the steps of all the approval procedures that already exist. That confusing approach appears all over the CRM configuration folders in SolMan.
Back to our screen, you see the newly created steps we added.
Save your changes.
Step 4: Assign the approval steps to your approval procedure. Double-click Assign Approval Steps and add the 2 new entries there.
Note 3: We changed the description of the partner function we used SDCR0002 and 3, though you are supposed to copy them to your own name space, but since we did not know all the implications and other features we may had to keep in mind when copying partner functions, we just decided to change the descriptions of the original ones to fit our needs for now. An upgrade may probably reverse those descriptions to the standard.
Note 4: Also, you need to enter a sequence for display purposes. Those are the 10 and 20 in the column that says ‘S..’
Note 5: The Rule Modeller Profile we used was AI_CM_AP_STEP. There is some theory to explain here, but to make it simple there are 2 ways for choosing an approval procedure for R4C. The simplest way is the Step Modeller or AI_CM_AP_STEP, which automatically knows which BPs are approvers for a particular step of the approval procedure. However, there is the modeller AI_CM_AP_PRO, which is to be created or maintained in the Web UI, and which is a set of simple or complex rules you define to “overwrite” the approval procedure your created from being used, to apply a possible different one, depending on the type of R4C as it is being entered. We stick to the simple one for this exercise.
Save your changes.
Step 5. Define if there is a sequence to follow or not. Double-click on Define Previous Step and add the entry that can easily tell the process which step depends on which one.
Note 6: We made step 2 to depend on step 1, and you will see further down that when the approval process is on step 1, step 2 becomes greyed out and will remain like that up until step 1 is approved. Only authorized BPs will have permission or not to approve step 2.
Save your changes.
Step 6. Define approval determination procedure. Double-click on Define Approval Determination Procedure and create a new entry.
Note 7: Recommendation is to call it something different than your approval procedure to avoid confusion. We did not follow that rule, so we are confused ;-).
Note 8: The whole approval procedure can be assigned to a R4C depending on rule policies that you can create in the Web UI (not part of the present trace), or can be automatically assigned to a R4C transaction type by default. We choose the latter.
Save your changes.
Step 7. Assign the approval determination procedure to the approval procedure. Select the entry you just created in Define Approval Determination Procedures and double-click on Assign Default Approval Procedure. As you see below, the fact that we used the same name for both things could make things confusing for some or not for other people. Congratulations if you are part of the latter ones.
Save your changes.
Piece 2: Remember the IMG location where we started working?
Step 8. Make this approval procedure you created the default for your R4C Transaction Type.
Once you select the IMG entry above, look for your R4C Transaction Type and populate the empty field with your approval procedure.
Step 9: Result:
As you can see the approval procedure locks steps 2 for edition, up until step 1 is approved.
Enjoy!!!
| User | Count |
|---|---|
| 93 | |
| 10 | |
| 10 | |
| 9 | |
| 9 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.