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.

Similar Messages

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

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

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 5.3 - Approver Not Found for STD Determinator

All,
I am using the standard approver determinator for super user access - Super Access Owner.
I have got an SPM Owner defined in the source system table for owners but CUP is returning an error message saying that the Approver is not found.
The other Custom Approver Determinators seem to work but the standard one referencing SPM owners does not. Am I looking in the right place?
Can any of you suggest how this can be corrected?
Please advise me if you have any recommendations.
Thanks,
Simon
Edited by: Simon Persin on Aug 17, 2009 11:51 AM Updated type on title.

Hi Simon,
Look at OSS note - 1350046. It may help.
Regards,
Alpesh

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.

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

CUP - Customizing Security & Roles

Hello,
Using the GRC AC 5.3 Security Guide, we've been customizing our front-end CUP roles to fit our needs. We're having trouble customizing one particular area, however.
Example:
When an approver (AEApprover role) or administrator (AEAdmin role) logs into CUP to view a request, they see a screen several tabs across the middle of the screen - Roles/Profiles, PD Profiles, Risk Violations, Mitigation, Superuser Access, Comments, and Request Reason.
We were hoping to get rid of the "PD Profiles" and "Superuser Access" tabs because we arn't using this functionality and feel it would be less confusing for the approvers if they didn't have to see it.
Looking through the security guide, however, we can't find any specific Actions that relate to these tabs. We've removed "ViewSelectPDProfiles" and "ViewSuperAccess" from the approver role but these seem to only relate to the buttons.
Am I missing something? Are there any other ways we can customize what middle tabs approvers see in CUP?
Thanks!!
Jes Behrens

Hello jes,
Yes you are right that these pemissions are for buttons and not for tabs. You can not remove any of these tabs.
Regards
Harleen
SAP GRC RIG

GRC AC 10 CUP : Provisioning of Approved roles (Line Item)

Hello Gurus,
We have configured CUP in GRC AC 10, and mapped a workflow for the same.
Now when a user request for new roles e.g.) 3 roles
Role 1 , Role 2 , Role 3 each roles has a different role owner.
When the request goes to the role owner for approval and 1 of the 3 role owner rejects the request the whole request gets rejected.
Is it possible to have functionality where roles which are approved will go ahead and get "Provisioned" and the whole request wont completely get rejected ??
Looking forward for your inputs !!
Thanks in advance.
Regards,
Victor

Hello Victor,
I guess you can work with the approval/ rejection level (stage 5 in the WF configuration).
Have a look at here: http://forums.sdn.sap.com/thread.jspa?threadID=1637574
Cheers,
Diego.

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!

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.

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

CUP Forks & Security Approver Determinator

Similar Messages

Maybe you are looking for