Approver Determinator in CUP

Freinds,
Any idea about 'BPO' approver determinator for workflow type Complaint user provisioning in CUP and from where this would get names from.
Thanks in advance.
Srinu

No...when you go to create stage..these is a standard approver determinator ' BPO' when you select workflow type 'compliant user provisioning'.
for examlpe if you select security lead as a approver in a stage then the workflow would pick the name from the approvers-> security lead...so if you select BPO in the stage where do we have to maintain the names of the BPO's.
Thanks,
Srinu

Similar Messages

SAP GRC 5.3 CUP: Approver Determinator "Super Access Owner"

Hi,
when configuring a stage, a standard approver determinator called "Super Access Owner" could be selected.My question is where to specify the Super Access Owner in SAP GRC CUP? In the Config Guide of SAP GRC AC 5.3 a hint explains on page 145
"If you select Superuser Access Owner as the approver determinator, the system
fetches the configured owner from the SAP system where the Superuser Privilege
Management is installed and assigns the request to that particular approver."
I do not really unterstand where to specifiy. Is it the former FireFighter in the backend.
Did anybody user this Approver Determinator already?
Thank you in advance.
Marco

Hi Marco,
Yes this approver is defined in the backend Firefighter which is now Super User Privelege Management. The Firefighter ID owner will be taken as the approver if we select Super User Access Owner in the CUP request. This option is basically being provided for Integration of Compliant User Provisioning and Super User Privelege Management for SAP GRC AC 5.3. You may now create a request to assign a Firefighter ID to a Firefighter in CUP and do not need to go to SPM for the same.
In case you do not want to use this approver, please create a Custom Approver Determinator for the same.
Hope this helps.
Harleen

CUP Forks & Security Approver Determinator

Hi All,
We are currently working on our CUP workflows and are planning on using forms to distinguish between manual provisioning (systems such as MDM console) and autoprovisioning (ABAP and java stacks). My question is, when we use the fork condition NON-SAP and SAP, where does CUP look to determine this? We are planning on using applications to setup our manual provisioning systems but I also know we could create them as dummy "other" connectors (although messy).
Also, what is the difference between Security Lead and Security approver determinators when configuring a stage? What IDs does CUP look at for these two? I only see Security Lead under Approvers.
Thanks!
Grace Rae

Hi Grace,
Forks only work for non-SAP connectors, so you's have to go for a dummy system if you really need fork. Alternatively you can chose an initiator based on roles, which will also allow you to fork the request on the first stage.
The security approver determinator is a group approver which looks for everyone with the UME role "AESecurity" and routes the request to them in parallel.
Frank.

Approver Determinator CUP (Controller) Question

Hello, I had a few questions when trying to use the (Controller) as Approver Determinator for our SPM work flow.
Everything is working perfectly fine using a CAD as the approver. But when I switch it over to the (Controller) I'm having some issues.
Questions:
1) Where would you configure the Controller's email address for approval notification? Guessing the SU01 record? This is different from other approvers who are configured within the UME
2) Won't the (Controller) need a CUP UME role to enter through the approval link sent out via email? Currently we only have controller in the backend ECC systems and view access to SPM reports through a UME view FF role.
3) Do we need to run a background job to send emails for the controller in the ABAP system or just the standard one in CUP?
Thanks!

There are "controllers" in SPM that you add to an FF_ID which then monitors logs. There is also a "controller" within the approver determinator drop down in a stage. I was wondering if these are the same. So if you use "controller" as your approver determinator for a certain FF ID in CUP will send for approval to the person define against the ID in the FF table.

CUP: Security Approver Determinator and emails

I have a stage that is set to use "Security" as the Approver Determinator. The approvals work for this stage but no emails are sent to the people that are in the security group.
Is it just expected that the security group will be monitoring the "My Work" tab for requests or is this a bug?
Does anyone else receive emails when routing a request to "Security"?
I have all of the emails configured in the stage. My other stages receive emails fine.
Running AC 5.3 SP07 patch 01
Regards,
-J

We use LDAP linked to UME for our user authentication. I double checked the users and the email addresses are being mappped correctly. The AESecurity Role also has users assigned.
I noticed that the email is not even placing the record in the "virsa_ae_emllog" table for the security stage. I can see it in there for the other stages.
I guess for some reason it is not finding the approvers.
I cannot post the log file because of the information that is contained in it. Is there anything in particulae that I can look for to see where there might be a problem? I searched for "Error" and only find one whihc the app seems to handle internally:
2009-05-19 12:36:20,501 [SAPEngine_Application_Thread[impl:3]_11] DEBUG WorkFlowBOHelper.java@2522:handleWFForNewPathStage() : A record doesn not exist in the WFHist table which is in same state as current record, so inserting : com.virsa.ae.core.ObjectNotFoundException: no dtos exist which are in the same state as the passing dto
2009-05-19 12:36:20,501 [SAPEngine_Application_Thread[impl:3]_11] ERROR no dtos exist which are in the same state as the passing dto
com.virsa.ae.core.ObjectNotFoundException: no dtos exist which are in the same state as the passing dto

Error in RAR while approving request from CUP

Dear GRC Gurus,
I am getting error while approving request in CUP for RAR. Checked the related threads for this issue but still not getting any solution.
Connectors are working fine. Also web service URL is maintained correctly and password for the same is working fine in backend.
Error message is
Risk analysis failed: Exception in getting the results from the web service : Service call exception; nested exception is: java.rmi.RemoteException:
Pl help.
Regards,
Muskaan

Hi ,
You need to clarify what you are trying to do, type of request, timeout time, moment it fails...
If you are referring to the RAR SOD web-service call from CUP, the timeout defined may be too short, problems on the web service/backend connectors configuration or performance/resources available. I advise you to see the SAP Notes below.
Troubleshoot issues with risk analysis, see the SAP Notes 1136379, 1049058, 1145700, 1234807, 1085586, 1061088, 1003239, and 1166368.
This is the most common issue between CUP and RAR when running the SOD analysis, and some times the only solution is to improve the performance of the server with more memory/processor.
Regards,
N

Approver determination using HR functions

Hello,
this is my first question on this forum, so be tolerant !!
Has anybody ever used HR functions (assigned at position level (S) in org structure) and corresponding HR search paths to determine approvers, instead of using PFCG roles ?
If yes, what are the constraints ? the gains against PFCG roles ? the performance issues ?
Rgds
Christophe

Gordan,
Approver determination in standard is independant from the role. It just get the first manager (hat in org. structure) of the requester, if no direct approver at requester level it goes to the next level, etc.
Usually this is not sufficient for customer and they develop their own determination (badi for dynamic wkf or adhoc object for classic wkf). It is just abap coding so any solution is possible.
About performance using HR path, I have no input. If you need to read all the organization and all beholders of the function, it certainly will be poor performance. If starting from requester and follow up the organization is enough, it should be the same as for the standard processing (manager or requester) .
Rgds,
Pierre

GRC CUP Custom Approver Determinator Question

I have a problem that when I add a new approver to one of my Custom approver determinators the change is only applied to new requests at that stage or rerouted requests. Has anyone seen this or know why?

Hi,
Lets say ABC is the approver and the requests that are approved in the previous level are with ABC approver queue. Since ABC approver is no more in the organization, you have changed the approver in the configuration and you require all the requests to be assigned automatically to the new approver.
If this is what you are looking at, its not possible.
You have to manually re-route the requests to the new approver.
Regards,
Raghu

SC Workflow: Runtime Actual Approval determination

Hi all,
I want to know who approved the Shopping Cart (SC) in runtime within the BADI so that comparing his Approval Limit with the cost of SC I can decide whether to skip or go for next approval levels.
Please help how to find it out. I have checked the history table but it contains a field "Type" whose possible values can only be either "changed" or "insert" and does not indicate "Approve" status for any agent....
Please help,
Thanks
Sangharsh

Hi
Try this BADI - BBP_WFL_APPROV_BADI.
<u>BBP_WFL_APPROV_BADI</u>
Determin. Approv. for n-Level. Dynamic Approval WFL
You need to make a logic in your case.
<u>Refer to the sample BADI logic.</u>
METHOD if_ex_bbp_wfl_approv_badi~get_remaing_approvers.
* Interface parameters:
* OBJECT_ID                  TYPE CRMT_OBJECT_ID                "Import
* OBJECT_TYPE                TYPE CRMT_SUBOBJECT_CATEGORY       "Import
* GUID                       TYPE BBP_GUID_32                   "Import
* ACTUAL_APPROVAL_INDEX      TYPE SWH_NUMC10                    "Import
* APPROVAL_HISTORY_TABLE     TYPE BBP_WFL_APPROVAL_HISTORY_BADI "Import
* ITEM_APPROVAL_HISTORY_TABLE TYPE BBPT_WFL_ITEM_APPROVAL_BADI   "Import
* APPROVAL_TABLE             TYPE BBPT_WFL_APPROVAL_TABLE_BADI "Export
* ITEM_APPROVAL_TABLE        TYPE BBPT_WFL_ITEM_APPROVAL_BADI   "Export
* NO_FURTHER_APPROVAL_NEEDED TYPE BOOLEAN                       "Export
* ITEM_APPROVAL_OBJ          TYPE BBPT_WFL_ITEM_APPROVAL_OBJ "Changing
* This is the 2nd example of the BADI implementation that includes
* dynamic spending limit approval for PO
INCLUDE <swfcntn01>.                  "Workflow
DATA:
   ls_header                   TYPE bbp_pds_sc_header_d,
   ls_approver                 TYPE bbp_wfl_approval_table_badi,
   lv_approval_index           TYPE swh_numc10,
   lv_guid                     TYPE crmt_object_guid,
   lo_new_instance             TYPE swf_bor_object,
   lt_approval_agent_obj       TYPE TABLE OF swf_bor_object,
   ls_wa_agent_obj             TYPE swf_bor_object,
   lo_user                     TYPE swf_bor_object,
   ls_approval_agent           TYPE bbp_wfl_approval_table,
   lv_index                    TYPE syindex,
   lv_usr01_name               TYPE ad_namtext,
   lt_approval_init_agents     TYPE TABLE OF bbp_wfl_approval_table,
   ls_wa_approval_init_agents TYPE bbp_wfl_approval_table,
   ls_wa_approval_history      TYPE bbps_wfl_history_line_badi.
* Business objects type (local constants)
CONSTANTS:
   c_po            TYPE crmt_subobject_category_db VALUE 'BUS2201',
   c_biddingdoc    TYPE crmt_subobject_category_db VALUE 'BUS2200',
   c_quotation     TYPE crmt_subobject_category_db VALUE 'BUS2202',
   c_grse          TYPE crmt_subobject_category_db VALUE 'BUS2203',
   c_invoice       TYPE crmt_subobject_category_db VALUE 'BUS2205',
   c_shop          TYPE crmt_subobject_category_db VALUE 'BUS2121',
   c_contract      TYPE crmt_subobject_category_db VALUE 'BUS2000113',
   c_salescontract TYPE crmt_subobject_category_db VALUE 'BUS2000114',
   c_avl           TYPE crmt_subobject_category_db VALUE 'BUS2206',
   c_invoicegrp    TYPE crmt_subobject_category_db VALUE 'BUS2207',
   c_vendor_obj    TYPE crmt_subobject_category_db VALUE 'BUS1006200'.
*** workflow approval states
CONSTANTS:
   c_wf_approved           TYPE bbp_wfl_approvalstate VALUE '0',
   c_wf_rejected           TYPE bbp_wfl_approvalstate VALUE '1',
   c_wf_not_instanced      TYPE bbp_wfl_approvalstate VALUE '2',
   c_wf_changed            TYPE bbp_wfl_approvalstate VALUE '3',
   c_wf_partialapproved    TYPE bbp_wfl_approvalstate VALUE '4',
   c_wf_step_in_process    TYPE bbp_wfl_approvalstate VALUE '5'.
CLEAR: lt_approval_init_agents[], lt_approval_agent_obj[],
         ls_wa_agent_obj, ls_approval_agent, ls_wa_approval_init_agents,
         ls_wa_approval_history.
* map input data to local data
* map char32 to raw16
MOVE guid TO lv_guid.
CASE object_type.
* ======================   shopping cart =========================== *
    WHEN c_shop.
*** get the details of the shopping cart
      CALL FUNCTION 'BBP_PD_SC_GETDETAIL'
        EXPORTING
          i_guid      = lv_guid
          i_object_id = object_id
        IMPORTING
          e_header    = ls_header.
      IF ls_header-total_value < 490000000.
*** 2 step approval
        CASE actual_approval_index.
          WHEN 0.
            ls_approver-approval_index = 1.
            ls_approver-approval_agent = 'USMANAGER1'.
            ls_approver-name = 'Arthur Manager1'.
            ls_approver-approval_description = 'First approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
          WHEN 1.
            ls_approver-approval_index = 1.
            ls_approver-approval_agent = 'USMANAGER1'.
            ls_approver-name = 'Arthur Manager1'.
            ls_approver-approval_description = 'First approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
          WHEN 2.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
          WHEN OTHERS.
            no_further_approval_needed = 'X'.
        ENDCASE.
      ELSE.
        CASE actual_approval_index.
*** 3 step approval
          WHEN 0.
            ls_approver-approval_index = 1.
            ls_approver-approval_agent = 'USMANAGER1'.
            ls_approver-name = 'Arthur Manager1'.
            ls_approver-approval_description = 'First approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 3.
            ls_approver-approval_agent = 'USMANAGER3'.
            ls_approver-name = 'Peter Manager3'.
            ls_approver-approval_description = 'Third approval step'.
            APPEND ls_approver TO approval_table.
          WHEN 1.
            ls_approver-approval_index = 1.
            ls_approver-approval_agent = 'USMANAGER1'.
            ls_approver-name = 'Arthur Manager1'.
            ls_approver-approval_description = 'First approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 3.
            ls_approver-approval_agent = 'USMANAGER3'.
            ls_approver-name = 'Peter Manager3'.
            ls_approver-approval_description = 'Third approval step'.
            APPEND ls_approver TO approval_table.
          WHEN 2.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER2'.
            ls_approver-name = 'Arnold Manager2'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 2.
            ls_approver-approval_agent = 'USMANAGER4'.
            ls_approver-name = 'Thomas Manager4'.
            ls_approver-approval_description = 'Second approval step'.
            APPEND ls_approver TO approval_table.
            ls_approver-approval_index = 3.
            ls_approver-approval_agent = 'USMANAGER3'.
            ls_approver-name = 'Peter Manager3'.
            ls_approver-approval_description = 'Third approval step'.
            APPEND ls_approver TO approval_table.
          WHEN 3.
            ls_approver-approval_index = 3.
            ls_approver-approval_agent = 'USMANAGER3'.
            ls_approver-name = 'Peter Manager3'.
            ls_approver-approval_description = 'Third approval step'.
            APPEND ls_approver TO approval_table.
          WHEN OTHERS.
            no_further_approval_needed = 'X'.
        ENDCASE.
      ENDIF.
* ====================== purchase order ============================= *
    WHEN c_po.
*** 1) Evaluate the list of spending limit approvers from BOR attributes
      swf_create_object lo_new_instance object_type   guid.
      swf_get_property   lo_new_instance 'SLManagerUserList'
                                          lt_approval_agent_obj[].
      lv_index = 1.
      LOOP AT lt_approval_agent_obj INTO ls_wa_agent_obj.
        swf_get_property ls_wa_agent_obj 'User' lo_user.
        swf_get_property lo_user 'NameWithLeadingUS'
                                ls_approval_agent-approval_agent.
        swf_get_property lo_user 'Name' lv_usr01_name.
        MOVE lv_usr01_name TO ls_approval_agent-name.
        ls_approval_agent-approval_index = lv_index.
        ls_approval_agent-approval_branch = 1.
        ls_approval_agent-initial_index = lv_index.
        ls_approval_agent-initial_agent =
                             ls_approval_agent-approval_agent.
        ls_approval_agent-approval_state = c_wf_not_instanced.
        APPEND ls_approval_agent TO lt_approval_init_agents.
        lv_index = lv_index + 1.
      ENDLOOP.
*** 2) Evaluate the list of remaining approvers. The actual approver
***    belongs to the list as well.
      LOOP AT approval_history_table INTO
                   ls_wa_approval_history WHERE type <> 'I'.
        LOOP AT lt_approval_init_agents INTO
                                  ls_wa_approval_init_agents.
          IF ls_wa_approval_init_agents-approval_index LT
                    ls_wa_approval_history-approval_index.
            DELETE lt_approval_init_agents.
          ENDIF.
        ENDLOOP.
      ENDLOOP.
* fill the import table
      CLEAR ls_wa_approval_init_agents.
      LOOP AT lt_approval_init_agents INTO
                                ls_wa_approval_init_agents.
        CLEAR ls_wa_approval_history.
        MOVE-CORRESPONDING ls_wa_approval_init_agents TO
                                          ls_wa_approval_history.
        APPEND ls_wa_approval_history TO approval_table.
      ENDLOOP.
      IF approval_table[] IS INITIAL.
        no_further_approval_needed = 'X'.
      ENDIF.
* ======================== contract ================================ *
    WHEN c_quotation.
      IF lv_index LT 2.
        ls_approval_agent-approval_description = '1st Approval'.
        ls_approval_agent-approval_index = 1.
        ls_approval_agent-approval_branch = 1.
        ls_approval_agent-initial_index = 1.
        ls_approval_agent-name = 'Hennes Kaempfer'.
        ls_approval_agent-approval_agent = 'USMANAGER4'.
        ls_approval_agent-approval_state = c_wf_not_instanced.
        APPEND ls_approval_agent TO approval_table.
        ls_approval_agent-approval_index = 1.
        ls_approval_agent-approval_branch = 1.
        ls_approval_agent-initial_index = 1.
        ls_approval_agent-name = 'Paul Reiter'.
        ls_approval_agent-approval_agent = 'USMANAGER5'.
        ls_approval_agent-approval_state = c_wf_not_instanced.
        APPEND ls_approval_agent TO approval_table.
        ls_approval_agent-approval_description = '2nd Approval'.
        ls_approval_agent-approval_index = 2.
        ls_approval_agent-approval_branch = 1.
        ls_approval_agent-initial_index = 2.
        ls_approval_agent-name = 'Dieter Mueller'.
        ls_approval_agent-approval_agent = 'USMANAGER33'.
        ls_approval_agent-approval_state = c_wf_not_instanced.
        APPEND ls_approval_agent TO approval_table.
      ELSE.
        no_further_approval_needed = 'X'.
      ENDIF.
ENDCASE.
ENDMETHOD.
Regards
- Atul

SRM SC 'N' step workflow - Approver list wrong approver determined

Hi Team,
I am facing a repetetive issue for a SRM shopping cart N-step approval workflow.
Issue description:
1. The approver list populated in 'Subworkflow for n-Level Approval SC' step is incorrect.
2. The BADI for N-step determines correct approver (After running the BADI seperately)
3. The cost assignment (WBS) determined is correct, so no chance of incorrect approver.
Example:
As per WBS (say) E.008.01.02, the correct approver is 'A'.
The BADI when run separately gives 'A' as the approver - which is correct.
But, when the workflow is triggered and the approver list populated in the Sub-workflow step it gives approver as 'B'.
There is no link so as how this approver 'B' is determined.
I am unable to find the step where this BADI is populating this value (Code) and what could be the reason.
Appreciate your help as I am having a production emergency!
Many thanks.
Harsh Dave

Hi Vinoth,
The Task 14007989 deals after the approval list is populated.
If you observe the workflow log of a SC/PO, the step N-step workflow (sub-workflow) itself determines the approval list and then comes the step 'Determine Next Approver' - TS14007989.
I tried to where-used list and it just yielded two FM's - BBP_WFL_DIN_APPR_CONTAINER_GET & BBP_WFL_DIN_APPR_BY_RULE_GET.
But the 1st one is to get only approvers which are already determined in container & 2nd one checks for further approval required (Flag = 'X', see the FM interface).
This one doesn't help!
Thanks for your help, Let me know if you have any more findings on this!

Approver question for CUP

Hi GRC guru's
As we are in the process of customizing CUP ,I have couple of questions so kindly help me out here
1. When requestor select roles which belong different approvers how does the request gets processed
example roles selected are Z_XYZ who's role approver is Tom and second role Z_ABC with role approver John , how is this request handled ?
2. When you run risk anlysisin CUP and you find out that there are risks and there is no mitiagtion control in RAR for risk produced , how will the approver proceed ? should he go back and perform the mitigation in RAR and then mitiagte the risk in CUP or is there a way to mitigate the new risk in CUP which can then be automaticallly pushed to RAR ?
3. Is there way to populate user group in the access request form and is there way to populate the license type in CUP?
Kindly clear my doubts ,Thanks in advance
Regards
Keith.

Hi Alpesh and all
I would like to follow up with your answer to Keith's question below.
1. When requestor select roles which belong different approvers how does the request gets processed
example roles selected are Z_XYZ who's role approver is Tom and second role Z_ABC with role approver John , how is this request handled ? Both the role owner would get email and can approve the request at same time. Unless untill both these approvers approve/reject the request, request can not move to next stage.
My question,
Is there a way to allow users to submit one request with 2 roles with different approvers, if the 1st approver approved the role, the 1st role to be provisioned to immediately without having to wait for the 2nd approver to approve the 2nd role?
The two roles both satisfy the critiria of the same initiator (attribute Role, and both roles are in the role list). Since the roles fall under the same path and stage (only 1 role owern approval stage), I noticed the 1st approved role was not provisioned until the 2nd role is approved. Is there a way to work arond that? It make sense to go ahead provision the 1st role without having to waiting for the 2nd role to be approved or rejected. The roles have the same approval requirement so they should use the same initiator and workflow path.
If you or anybody knows the work around, I would appreciate your sharing the info.
Thanks.
p.s.
I did a test to submit a request with 2 roles, each role satisfy a different workflow initiator therefore different paths are used. 1st role was approved through 1st path and provisioned immediately while 2nd role was waiting in approval stage in the 2nd path. The request is closed once both path were completed.

MDM workflow - dynamic approver determination

Hallo,
in MDM workflow, i see that in the visio workflow definition of the approval step, it is possible to set approvers. This sound to me like a static approval definition.
Let say that according to some field value I want to determine different approvers, meaning if Product category is 1 approver is X, if Product category is 2 approver is Y, etc..
Is this possible to achieve?
How?
thank you in advance,
Regards,
Marco

Marco,
I am assuming you have 3 approvers X, Y and Z. Create 3 validations for all 3 cases:
Validation A: Category =1 => goes to approver X
Validation B: Category =2 => goes to approver Y
Validation C: Category =3 => goes to approver Z
Start -> Branch (Add validation A) -> Form 2 processes (1 which is TRUE goes to Approver X and for false it is either Y or Z)
            -> (TRUE) -> Approver (Assign X)
            -> (FALSE) -> Branch (Add Validation B) -> Form 2 processes (1 which is TRUE goes to Approver Y and for false it is Z)
            -> (TRUE) -> Approver (Assign Y)
            -> (FALSE) -> Approver (Assign Z if this the default approver else add one more iteration)
I hope this should work.

SP10 - multiple approver problem with CUP

We have SP10 (patch 1) in our development system and cannot move forward to production because of a real show stopper. I have currently reported this to SAP thru an OSS message (and it is in development) but would like to know if anyone else is having this issue with SP10. (this happened even before applying patch 1)
We have multiple approvers when creating NEW users or CHANGING users in CUP. We have it configured to allow just one of the approvers to approve before going on to the next stage. Since we put in SP10, CUP is requiring ALL approvers to approve the request before going on to the next stage. We get the following message when one of the approvers approve the request: Request no: 5020. is approved, pending for other Approvers.
I've seen this reported for UAR and SOD but not for CUP. In fact, there is a fix for UAR in Patch 1 of SP10. I applied this patch but it hasn't fixed the CUP issue. I also don't have the issue when rejecting a CUP request, or when approving it through the configuration --> Request --> Administration screen (what I consider the Back-door since only security administrators get the configuration area).
Thanks for your input.
Peggy

Christian,
I totally agree with you.
The good news is.... We installed SP11.1 and the multiple approver problem is fixed.
We have decided to leave our production system at SP8 until this system settles down a bit. Of course, this means we can't use many of the new fixes and features (such as UAR). We use our sandbox system to apply new support packs and do very rigorous testing. And our DEV system is at SP8 too.
Good Luck.
Peggy

PO Approver determination

Hello experts;
Can someone explain to me how does the system determine who's the approver of a PO, I tried a rule with agent determination still I can't direct it to the right approver.
Is there anything in the PO that can indicate to the WF to send the work item to a user based on the department that ordered the goods.
Thanks;
Ibou

Ibou,
First of all PO Process and Workflow are different processes.
Now coming to your question, Go to SPRO and follow path:
Materials Management->Purchasing->Purchase Order->Release Procedure for PO->Define Release proc for PO
then select workflow , you will find one table there,
fill that table with OT (your object type) and AgentID (with object id) also Group and code.
when rule will executed it should take according to that Id.
I have not tried myself but pretty much sure that it would definitely work.
yes one more thing you might require: go to Release code and enter Group Code and fill the workflow coloumn in that table, you can check in that FM also it is picking those values, possible values for Workflow column are (blank, 1 and 9) which you can find in FM.
It will 100% solve your issue.
Reward points if solved.
thanks for earlier rewards
Cheers
Jai

Shoppingcart Approver Determination(Org Structure)

hi Gurus,
I am working on class scenorio SRM 4.0 Version project.my problem is described as mentioned below.
User is creating a shopping cart with the value 5500 Euro.In the Org Structure User manager(Manager A) has the approver limit as 5000 Euros.So based on shopping cart value IT should goto Next Level manager(Manager B having approval limit 10000 Euro).
System determined correct Manager(Manager B).But User has added the " Add Approver" option in the shoppingcart and replaced with Manager A saved the shopping cart. Finally Manager A has approved the shopping cart.
My question is Manager A having the Approval Limit 5000 but he approved the work item of User shopping cart value 5500.
Is it standard process or any bug in the SAP SRM.
Or any OSS note to resolve the issue...
My Client reported like that how system allowed above the shopping cart approver to Manager A.
Is it behaving Farward Work Item and that time system wont check the Apprver limit know....
Please correct me my assumption is wrong...
Please reply me as soon as possible.
Regards,
Satish.

Hi
You must implement the Dynamic Spending LImit Approval in SRM
You should use Expression 0B_SC_SPENDLIMAPPR02 for the Event at this Process Level.
Then use BADI Implementation /SAPSRM/BD_WF_SC_RR_MANAGER for agent determination.
BADI Implementation /SAPSRM/BD_WF_CONFIG_SC_SL for creation of Dynamic Process level.
In other words, activate the above to badi Implementations and use the RR_MANAGER in the parameter for Agent determination in process level config.
This will work as follows:
Expression will evaluate whether the Previous approver or Creator of the SC has SL more than SC Value or not. If not, System creates a dynamic process level and assign the first approver. Then again it re-evaluate the BRF expression and figure out if the first approver had SL more than the SC value, if not, system determines next approver and creates a new process level dynamically. This process goes on until SC is covered with a manager with enough spending limits.
I hope this will help you sorting out your issue around SL Approvals
System wont allow you to remove the approvers which ve been picked by Workflow. Only Manually added approvers can be removed
Regards
Virender Singh

Approver Determinator in CUP

Similar Messages

Maybe you are looking for