嗨，

您确定问题与SRM PO有关吗？
对于SRM PO，我们通常具有流程控制的工作流程或应用程序控制的工作流程，并且您在PO（BUS2201）中使用哪种方案？

请澄清这一点，以便我提供更多信息。

BR，

常春藤

你好Niharika，

实际上，此问题可能有多个根本原因。 由于其他一些BAdI实现正在干扰并且会导致重新启动或进行一些并非全部需要的更改，因此问题经常发生。 这些典型的BAdI是BBP_DOC_CHANGE和/SAPSRM/BD_WF_PROCESS_RESTART。

要分析问题，您也可以使用以下指南：

1749991-策略未确定任何批准人

最好的问候

佐尔坦

config.png 感谢您的回答。

是的，我们在所有其他方案（如PO，SC，RFx）中都使用过程控制的WF，但对于此特定方案，我们要检查PO是否为变更版本，动态工作流会触发一切正常，直到我们刷新为止。

/SAPSRM/IF_EX_WF_RESP_RESOLVER〜GET_APPROVERS_BY_AREA_GUID
 环回ostyp_ref_tab进入ls_object。
       如果ls_object不是INITIAL。
         lo_area_context？= ls_object。
         lo_decisionset = lo_area_context-> get_mo_decisionset（）。
         process_level = lo_decisionset-> get_mo_process_level（）。
         lv_pos = process_level-> get_mv_level_position（）。
         如果lv_pos_old是INITIAL。
           lv_pos_old = lv_pos。
         ELSEIF lv_pos_old> lv_pos。
           出口。
         ELSEIF lv_pos_old  get_mv_resp_resolver_param（）。
       万一。
     结局。
 上面的代码-process_level返回批准者的顺序和用户ID，直到我们按命令返回正确的顺序和批准者列表，但刷新后它从第二层开始。
 在刷新的情况下，我注意到第一个批准者的Level_status状态为ACTIVE而不是VALID。

 请指导，让我知道是否需要更多信息。 谢谢