Manage Workflows for Centrally Managed Purchase Requisitions
Application component: Processing Purchase Requisitions centrally
App type: Transactional
Line of business: Sourcing and Procurement
Leading industry: Cross Industry
Solution capability: Central Purchasing (S/4, Ariba Ctrl Proc.)
Description:  With this app, you can configure workflows to approve the centrally managed purchase requisitions as an administrator. The app provides several options to define preconditions for the release of centrally managed purchase requisitions. It also provides options to determine the approvers and reviewers of their release. The approval process can be either automatic or a one-step or multi-step process. If a workflow for with one or more steps is activated and the configured start conditions are fulfilled, the approval process is initiated. Depending on the role you are assigned to, you can determine an approver and reviewer. The approval process starts when a workflow with one or more steps is activated and the preconditions you have assigned to it are met. 
You can use the Manage Workflows for Centrally  Purchase Requisitions to create rules for approval of  Purchase Requisitions from various connected systems.
Key features:  You can use this app to:  Create a new item level or header level workflow.   Define the validity period of the workflow.   Define start conditions for a workflow, such as the company code, purchasing group, purchasing organization, and total net amount. You can also use the value help enabled for these filters to define the start conditions for a workflow. The preconditions that you can select are determined based on whether the workflow is for the overall release or item-level release of a purchase requisition. You can add multiple preconditions, if required. The workflow starts only if all the preconditions are satisfied.   Define the order in which the start conditions of existing workflows are checked. If you defined several workflows, the start conditions are checked in the order you defined the workflows. As soon as the start conditions for a workflow are met, that workflow is used. This ensures that only one workflow in the list of your defined workflows is started, even if several workflows have matching start conditions.   Define the step sequence by adding and configuring the approval and review steps in the workflow. In the review steps, you can define the reviewers or people responsible for monitoring the progress of the workflow. When a workflow is started, all the reviewers are notified. The reviewers can then track the progress of the workflow. Workflow items pertaining to review steps can only be monitored, and cannot be approved, rejected, or sent back for rework. Step Information For Approval Steps For Reviewer Steps  Step Name  This field is optional. Enter the name of the approval step   This field is optional. Enter the name of the approval step   Step Type  The step type can be one of the following:  Automatic Release of Centrally Managed Purchase Requisition: Release of the centrally managed purchase requisition is performed automatically. By default, this workflow is activated. Recipients are determined automatically   Release of Centrally Managed Purchase Requisition: You can define the recipients and other step details for the release of the centrally managed purchase requisition.    Release of Reworkable Centrally Managed Purchase Requisition: You can define the recipients and other step details. This step type provides approvers with an additional option to send back centrally managed purchase requisitions for rework. For items subject to this workflow, approvers have an additional option Request Rework in the My Inbox app. Approvers can choose this option and request the central purchaser to make changes.Note To utilize this step type, you need to create a new workflow scenario or copy an existing one and activate it. Workflow scenarios created before SAP S/4HANA 2023 will be invalid.     The step type can be Review Workflow of Centrally Managed Purchase Requisition. You can define the recipients and other step details for the review of the centrally managed purchase requisitions.   Step Properties - Is Optional Step  You can mark a workflow step as optional using the step property, Is Optional Step. This is an optional field, and by default a step is considered as mandatory. If a workflow step is marked optional and an approver cannot be determined for the step, then the step gets skipped and the workflow automatically moves to the next step, if any.   Not Applicable   Step Properties - Exclude Restricted Agents Determined by BAdI  You can choose to exclude restricted agents from being approvers of the centrally managed purchase requisition. By default, the restricted agents are not excluded. On choosing the option Exclude Restricted Agents Determined by BAdI, the agents set by the the BAdI Enhancement of Flexible Workflow Properties are excluded from being approvers of the workflow step.Note After exclusion, if no recipients are determined, the workflow will move to error unless the step is marked optional.   Not Applicable   Recipients  The recipient selection can be based on the following:  User-based: You can choose a specific user from People Picker for Purchase Requisition Approver.   Role-based: You can choose from the following roles.   Agent Determination by BAdI: If you use the this role, the recipients are determined based on the custom logic defined in the BAdI, Determination of Workflow Agents for Purchasing Documents (MMPUR_WORKFLOW_AGENTS_V2).Note   An additional importing parameter STEPINFO in this BAdI provides the current step number and the total number of steps in the workflow. However, to make use of this new parameter, please ensure that you not only adapt your BAdI implementation, but also create a new workflow.   The importing parameter TASKTYPE in the BAdI provides the information about the type of task in context of which the BAdI is invoked. Ensure the value you provide here is Approval.     Central Purchasing: You can choose the central purchasing scenario.   Manager of Last Approver: If you use the this role, you have to maintain the relationships between the employees and their managers. This ensures that the workflow can find the correct approver.   Workflow Administration: If you choose this role, it is necessary to define the team functions using the app Manage Teams and Responsibilities.    You can also add multiple recipients, and choose if the step needs to be approved by one or all of the recipients.   The recipient selection can be based on the following:  User-based: You can choose a specific user from People Picker for Purchase Requisition Approver.   Role-based: You can choose from the following roles.   Agent Determination by BAdI: If you use the this role, the recipients are determined based on the custom logic defined in the BAdI, Determination of Workflow Agents for Purchasing Documents (MMPUR_WORKFLOW_AGENTS_V2).Note The importing parameter TASKTYPE in the BAdI provides the information about the type of task in context of which the BAdI is invoked. Ensure the value you provide here is Review.   Central Purchasing: You can choose the central purchasing scenario.   Manager of Last Approver: If you use the this role, you have to maintain the relationships between the employees and their managers. This ensures that the workflow can find the correct approver.   Workflow Administration: If you choose this role, it is necessary to define the team functions using the app Manage Teams and Responsibilities.    Note The reviewer determination is step-agnostic. Hence it is recommended to avoid configuring multiple role-based review steps with the same role.   Step Conditions  You can define the step conditions that need to be satisfied before the step is executed.   You can define the step conditions that need to be satisfied before the step is executed.   Deadlines  You can define the deadline by which the step should be completed, beyond which an overdue notification is sent to the approver. The workflow deadline can be specified in minutes, hours, days or workdays. Workdays are determined based on the factory calendar. The factory calendar can be defined using the BAdI -Determination of Factory Calendar for Workflow Deadline (MMPUR_PROC_WF_FACTORY_CALENDAR). If there is no custom logic defined, all days of the week are considered as workdays. You can define timelines for workflow steps, to start either after a workflow has been approved or after a workflow step has been created. If a workflow step exceeds the defined timeline, you can choose to either ‘Mark step as overdue’ or ‘Send mail notification’. If you choose to ‘Send mail notification’, then you must select a mail template and the recipients of the mail notification.Note The email templates must be maintained by the administrator using the app, Manage Email Templates. For more information, see How to Configure the Flexible Workflow for Centrally Managed Purchase Requisitions   You can define the deadline by which the step should be completed, beyond which an overdue notification is sent to the approver. The workflow deadline can be specified in minutes, hours, days or workdays. Workdays are determined based on the factory calendar. The factory calendar can be defined using the BAdI -Determination of Factory Calendar for Workflow Deadline (MMPUR_PROC_WF_FACTORY_CALENDAR). If there is no custom logic defined, all days of the week are considered as workdays. You can define timelines for workflow steps, to start either after a workflow has been approved or after a workflow step has been created. If a workflow step exceeds the defined timeline, you can choose to either ‘Mark step as overdue’ or ‘Send mail notification’. If you choose to ‘Send mail notification’, then you must select a mail template and the recipients of the mail notification.Note The email templates must be maintained by the administrator using the app, Manage Email Templates. For more information, see How to Configure the Flexible Workflow for Centrally Managed Purchase Requisitions   Exception Handling  By default, the workflow is cancelled when an exception occurs in its step sequence. You can choose actions and action results for these exceptions:  Exception: Rejected  Required Action: Do nothing   Action Result: When a step is rejected, you can configure the action result to cancel the workflow, repeat the step, continue from subsequent step, or restart the workflow from beginning.     Exception: Rework Requested  Required Action: Rework Centrally Managed Purchase Requisition   Recipients: The recipients to whom the centrally managed purchase requisition is sent for rework.  User-based: You can choose a specific user from the people picker.   Role-based: You can choose the appropriate role:  Determined automatically: Not to be selected in case of rework. An error message is displayed if this option is selected.   Agent Determination by BAdI: If you use this role, the recipients are determined based on the custom logic defined in the BAdI Determination of Workflow Agents for Purchasing Documents ( MMPUR_WORKFLOW_AGENTS_V2).   Central Purchasing: You can choose the central purchasing scenario.   Workflow Administration: If you use this role, it is necessary to define the team functions using the Manage Teams and Responsibilites app.   Workflow Initiator: If you use this role, the initiator of the workflow becomes the recipient.       Deadlines: You can define the deadline by which the rework should be completed, beyond which the step is marked as overdue. The rework deadline can be specified in minutes, hours, days or workdays. Workdays are determined based on the factory calendar. The factory calendar can be defined using the BAdI Determination of Factory Calendar for Workflow Deadline (MMPUR_PROC_WF_FACTORY_CALENDAR). If there is no custom logic defined, all days of the week are considered as workdays.   Action Result: When a centrally managed purchase requisition is submitted after rework, you can configure the action result to continue to next approver, repeat the step to same approver, or restart the workflow from beginning. Note that if the rework changes are restart-relevant, then the workflow is restarted irrespective of the action result chosen.Note Also applicable for the exception Rejected, if the required action is Rework Centrally Managed Purchase Requistion.       Not Applicable     Navigate to the details of an existing workflow from the list page.   Activate or deactivate an existing workflow.   Copy an existing workflow and modify it according to your requirements or add a new workflow.   Use Responsibility Management to determine the workflow approvers of the document. To determine the workflow approvers of the document, you can use the existing roles such as the Agent Determination by BAdI, Manager of Last Approver, Workflow Administration, or you can use the role Central Purchasing delivered by Responsibility Management.   Use the feature Automatic Release of Centrally Managed Purchase Requisition delivered by SAP as an alternative option. By default, this workflow is activated.   Note   Configuration of the overall release of purchase requisition documents in connected systems is not recommended if items of the same documents are already configured for approval in the hub system.   If you have rejected a purchase requisition item that was created in the SAP ERP connected system using the workflow process, then the approval status for the purchase requisition item is set to Release Refused. Furthermore, you cannot edit such purchase requisition items in the connected systems.   Workflow activity of central purchase requisition from third party systems are supported. For more information see the section SAP S/4HANA Central Purchasing Integration with Third Party System in SAP Best Practices Explorer at https://rapid.sap.com/bp/ under SAP S/4HANA  On Premise  SAP Best Practices for SAP S/4HANA (on premise)   Sourcing and Procurement  Central Procurement  Central Purchasing (2XT) guide.   
Business roles: Configuration Expert - Business Process Configuration
Configuration Expert - Business Process Configuration : 
Performs business process configuration and other tasks required for implementing SAP solutions, such as scoping the solution, configuring the business processes, performing manual rework activities, and changing business process configuration.