2020-09-26 22:15发布
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
大家好,
有人在一个机会内建立多个审批流程/工作流程的业务需求吗? 如果是这样,您如何解决并实施解决方案?
开箱即用,C4C机会只有一个批准工作流程。 我们的业务需求需要3个不同的审批门,然后才能设置获胜/失败的机会
感谢任何建议
桑迪科,你好
您可以在C4C中获得多步批准(即用型)。 含义,案例:1
如果期望转速超过100000->批准将授予员工A
如果期望转速大于1000000->批准将授予员工B
如果期望转速大于2000000->批准将授予员工C
如果是多级批准,则情况2
如果期望的转速大于1000000->批准将授予员工A->一旦A批准,则必须批准给B,然后再批准给C。这是顾问必须进行配置才能实现的目标。 例如,超过1000000,批准转到A,一旦A批准,状态字段将必须通过工作流规则更新自定义字段" Level 1 Approved"。 在第二个批准规则中,我们可以配置是否将" Level1批准"设置为"是"并且Exp销售值为1000000,然后触发到B。
案例3:第三,可能要经过三个不同的人批准,并且所有人都必须批准,交易才能继续进行:
批准由三人组成,事务将处于"正在批准"状态,直到所有人都批准为止。 这可以通过单击所有必需的批准复选框来实现,工作分配字段具有"直接批准者",这意味着在参与方的机会中具有直接批准者角色的员工有权获得批准,如果有多个直接批准者,则 他们都必须批准有机会继续前进。
此致
Seshu
Hi Mark,
取决于您是否要通过SDK/编码或通过关键用户工具来执行此操作。 对于SDK,必须记录批准流程,然后实施您的技术资源。
通过KUT,您可以将微调,扩展字段,规则编辑器,代码列表限制,页面布局(如果需要)和工作流程规则结合起来使用。
1。 在批准者1-3的微调中创建新的参与者角色定义。 那将是3个条目。 您还可以将它们添加为参与方,以便您对参与方进行微调。 如果每个帐户都附有相同的批准人,则可以在设置主数据后设置自动确定。 如果对于每个机会都是唯一的,则用户必须通过在机会中销售团队方面选择员工来手动设置每个批准者。
2。 创建3-6个扩展名字段。 如果可以通过状态或UI上已有字段中的某些其他条件触发批准工作流程的条件,则只需3个扩展字段。 您将使用每个批准者的三个字段来选择一个用于批准的下拉选项(已批准,已拒绝,需要修订)。 您可以使用规则编辑器使该字段成为必填字段,而所有其他字段仅在满足条件后直到设置批准1才显示。 当满足其批准条件时,您将对每个批准字段执行此操作。 您还可以使用页面布局来确保只有批准者可以打开要编辑的字段,而那些仅请求批准的人只能看到显示内容。 再次使用规则编辑器,以确保在设置了批准1的条件时,仅打开用于第一次批准的扩展名字段进行编辑。
3。 如果您的用户已经可用的字段无法满足您的批准条件,则可能需要再触发3个字段来批准阶段。 用户可以手动设置(可以使用规则编辑器来确保设置),也可以通过工作流通过条件进行设置。 一旦设置了"需要批准的扩展名"字段1,这将成为由定制参与方批准人1设置"批准结果1-"已拒绝,已修订,已批准"字段的条件。
4。 您可以使用工作流,根据设置的第3步中已经可用或自定义字段中的条件,将电子邮件发送给每个批准者。 在确定接收者的情况下,您可以根据哪一步选择批准者之一。 步骤3所需批准将选择接收方批准人3。因此,您将使用3种工作流程,可能是3种不同的形式。
5。 最后,您还可以编写代码列表限制,以阻止将机会设置为"获胜/失败"。 根据您何时可以设置某种状态的规则,这可能需要多个代码列表限制。
关于,格雷森
最多设置5个标签!
桑迪科,你好
您可以在C4C中获得多步批准(即用型)。 含义,案例:1
如果期望转速超过100000->批准将授予员工A
如果期望转速大于1000000->批准将授予员工B
如果期望转速大于2000000->批准将授予员工C
如果是多级批准,则情况2
如果期望的转速大于1000000->批准将授予员工A->一旦A批准,则必须批准给B,然后再批准给C。这是顾问必须进行配置才能实现的目标。 例如,超过1000000,批准转到A,一旦A批准,状态字段将必须通过工作流规则更新自定义字段" Level 1 Approved"。 在第二个批准规则中,我们可以配置是否将" Level1批准"设置为"是"并且Exp销售值为1000000,然后触发到B。
案例3:第三,可能要经过三个不同的人批准,并且所有人都必须批准,交易才能继续进行:
批准由三人组成,事务将处于"正在批准"状态,直到所有人都批准为止。 这可以通过单击所有必需的批准复选框来实现,工作分配字段具有"直接批准者",这意味着在参与方的机会中具有直接批准者角色的员工有权获得批准,如果有多个直接批准者,则 他们都必须批准有机会继续前进。
此致
Seshu
Hi Mark,
取决于您是否要通过SDK/编码或通过关键用户工具来执行此操作。 对于SDK,必须记录批准流程,然后实施您的技术资源。
通过KUT,您可以将微调,扩展字段,规则编辑器,代码列表限制,页面布局(如果需要)和工作流程规则结合起来使用。
1。 在批准者1-3的微调中创建新的参与者角色定义。 那将是3个条目。 您还可以将它们添加为参与方,以便您对参与方进行微调。 如果每个帐户都附有相同的批准人,则可以在设置主数据后设置自动确定。 如果对于每个机会都是唯一的,则用户必须通过在机会中销售团队方面选择员工来手动设置每个批准者。
2。 创建3-6个扩展名字段。 如果可以通过状态或UI上已有字段中的某些其他条件触发批准工作流程的条件,则只需3个扩展字段。 您将使用每个批准者的三个字段来选择一个用于批准的下拉选项(已批准,已拒绝,需要修订)。 您可以使用规则编辑器使该字段成为必填字段,而所有其他字段仅在满足条件后直到设置批准1才显示。 当满足其批准条件时,您将对每个批准字段执行此操作。 您还可以使用页面布局来确保只有批准者可以打开要编辑的字段,而那些仅请求批准的人只能看到显示内容。 再次使用规则编辑器,以确保在设置了批准1的条件时,仅打开用于第一次批准的扩展名字段进行编辑。
3。 如果您的用户已经可用的字段无法满足您的批准条件,则可能需要再触发3个字段来批准阶段。 用户可以手动设置(可以使用规则编辑器来确保设置),也可以通过工作流通过条件进行设置。 一旦设置了"需要批准的扩展名"字段1,这将成为由定制参与方批准人1设置"批准结果1-"已拒绝,已修订,已批准"字段的条件。
4。 您可以使用工作流,根据设置的第3步中已经可用或自定义字段中的条件,将电子邮件发送给每个批准者。 在确定接收者的情况下,您可以根据哪一步选择批准者之一。 步骤3所需批准将选择接收方批准人3。因此,您将使用3种工作流程,可能是3种不同的形式。
5。 最后,您还可以编写代码列表限制,以阻止将机会设置为"获胜/失败"。 根据您何时可以设置某种状态的规则,这可能需要多个代码列表限制。
关于,
格雷森
一周热门 更多>