SRM 5.0 Approval WF fragment has no user assignment

[Former Member]

Hi,

While changing approvers in the approval preview the system displays message 'Approval Workflow fragment has no user assignment'. In our case WS10000271 and TS10407972 are both set as general tasks. Any idea why the system would be generating this message?

Thanks,

Jerry

[Former Member · Accepted solution]

Hi,

Have you assigned any agents by default?

BR,

Disha.

[pvanhoove · Accepted solution]

Hello,

If all your task are classified as general, this is a bug in a FM (SRM5, SP4). No idea if a note exist for this but check source of function BBP_PDH_WFL_APP_ASSIGNTYPE_GET, the task type (WF, TS) is hard coded, you may want to change it )

FUNCTION bbp_pdh_wfl_app_assigntype_get.

*"----

---

""Lokale Schnittstelle:

*" IMPORTING

*" VALUE(IV_TASK) TYPE SWD_STEP_T OPTIONAL

*" EXPORTING

*" VALUE(EV_ASSIGNMENT) TYPE CHAR1

*" TABLES

*" ET_POSSIBLE_AGENTS STRUCTURE SWHACTOR OPTIONAL

*"----

---

DATA:

lv_general_task LIKE p1217-general,

lt_related_agents TYPE swhactor OCCURS 0 WITH HEADER LINE,

lv_task TYPE swd_step_t.

*{ INSERT DE2K901025 1

*PVA correction

data: lv_otype type OTYPE.

lv_otype = iv_task(2).

*} INSERT

lv_task = iv_task+2.

• evaluate the agent assignment of the whole workflow fragment

CALL FUNCTION 'RH_TASK_AGENTS_INDEX'

EXPORTING

*{ REPLACE DE2K901025 2

*\ task_otype = 'WS'

*PVA correction

task_otype = lv_otype

*} REPLACE

task_objid = lv_task "workflow fragment

IMPORTING

act_general = lv_general_task

TABLES

related_agents = et_possible_agents

EXCEPTIONS

no_active_plvar = 1

no_agents_of_task_found = 2

no_task_otype = 3

OTHERS = 4.

Rgds,

Pierre

[Former Member · Accepted solution]

Hi Pierre,

That seems to be the problem as when the system attempts to check the agent assignment for TS10008126 it's actually using WS10008126 due to the hardcoded object type.

What concerns me is that there are no fixes for a problem that seems to occur each time you change the approver. I'm working at two different SRM sites and the error is occurring at each site.

I'll report the problem to OSS.

Thanks,

Jerry