Enabling Flexible SAP Workflow in Purchase Requisition
Enabling Flexible Workflow in Purchase Requisition
http://blog.sina.com.cn/s/blog_cfa68e330102zoax.html
In this blog we will go through the steps required to enable flexible workflow for Purchase Requisition in S/4 HANA Cloud. Along with that we will see what are the different configurations available with Purchase Requisitions Flexible Workflow.
Flexible workflow is alternatively called as scenario based workflow, since here user can configure different workflow process using the same workflow scenario.
Steps to follow to enable Flexible Workflow
Step 1:
Flexible workflow in Purchase Requisition is enabled based on the document type.
Manage you Solution App ->Configure your solution -> Requirements Processing -> Approval Settings for Purchase Requisition -> Configure
In Purchase Requisition , flexible workflow can be set at header or item level which is again based on document type.
Configuring Header/Item level(checkbox Overall Req. rel.) – Enabling the check box Overall Req. rel. sets the document type for header level approval. Disabling the checkbox sets the document type for item level approval.
Here we have enabled NB for item level approval and NBS for header level approval.
Configuring flexible workflow(Flexible Workflow checkbox) – Enabling this checkbox activates flexible workflow for Purchase Requisitions created with this document type .
In this case , we have enabled header flexible workflow against document type NBS and item flexible workflow against NB.
Step 2:
Now you configure workflow by defining the start condition based on which you want to trigger the approval process , who will be recipients of the workflow etc.
Manage workflow for Purchase Requisition App : Here we have two workflow scenarios "Overall Release of Purchase Requisition" for configuring header workflows and "Release of Purchase Requisition Item" for item level workflows.
Here you can define the order of the workflow by using the "Define Order" button . When the workflow is triggered during creation of Purchase Requisition, the workflows are evaluated based on the order. That is it will start evaluating from the workflow with order 1, if the Purchase Requisition created doesn't satisfy the preconditions in workflow with order 1 then it will go to order 2 workflow and so on.
Here you can see there is a workflow "Automatic Approval of PR" at header and "Automatic Approval of PR Item" at item level. This is a pre-delivered content and it is delivered as active as this is the fallback option i.e. if none of the workflow configured are picked up , this automatic approval workflow is picked up and the Purchase Requisition is approved automatically. Since this is a fallback option order of this workflow is always the highest one i.e. the highest number.
Note: To avoid any issue with the approval process which might result in hanging Purchase Requisition , pre-delivered content of automatic approval of workflow should always be active.
You can configure new workflow by using the "Add" button or you can copy an existing workflows using "Copy" button and adding your changes to the workflow .
Configuring Header workflow:
Preconditions are basically the conditions on which you want the workflow to be triggered. In this case if the total value of the Purchase Requisition is equal to or greater than 100 EUR , this workflow will be picked up for approval process.
At header workflow scenario , you have 4 different condition to choose from. You can add more than one precondition which are separated by AND i.e. only when both the conditions are satisfied this workflow will be picked up. For few fields a value help is there to choose from as in this case company code and currency.
After this you need to configure the steps. You can have one or more steps.
You click on add to configure the steps. Here you can choose whether you want to go for automatic approval or manual approval(Overall Release of Purchase Requisition) for this step.
Once you choose Overall Release of Purchase Requisition, you need to define who will be the recipient for this step in approval process.
In recipients you have two options. Either you can define the "Role" of the recipient , so the system will evaluate who is the recipient at runtime depending upon the users assigned to that role or you can use "User" wherein you will directly assign the users who are the recipient of this step. Single or multiple recipients for the same step is supported to achieve parallel approval.
At the same time you can mention whether you want this to be approved by all the recipients of the step to move it to the next step or approval by one of the recipients is suffice to move the process to the next step. This is enabled by choosing "One of the recipients" (only one recipients approval is suffice) or All of the recipients(all recipients need to approve to move to next step).
In case of header workflow , the above three roles are available. If you want to implement you own logic to derive the recipient user, Agent Determination BADI need to be implemented.
In case of Users more than one user can be chosen from the value help as recipients.
Preconditions can be used at each step level as well. Step level precondition ensure that this particular step will be triggered only if the preconditions are satisfied. The precondition available here are the same as the one above.
For exception handling, there are different option to choose from for what you want to do if this step is rejected by the recipient of the step.
Once you have configured all these, this workflow need to be saved and activated . You can also change the order using "Define Order".
Configuring Items workflow:
Configuring item level workflow is same as header workflow . Now only difference are with respect to preconditions and "Role" recipients.
Preconditions
Role based Recipients
Once all preconditions, steps and recipients added , save and activate.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29829936/viewspace-2650258/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SAP FIORI My Inbox App – Custom Purchase Requisition WorkflowAPPUI
- 在 Microsoft Dynamics NAV 2018 Setting Up and Using a Purchase Approval WorkflowROSAPP
- SAP MM Purchase Order History CategoryGo
- SAP Workflow常用TCODE
- An introduction to SAP Business Workflow
- SAP MM Return Purchase Order之使用
- SAP Fiori 應用 Manage Workflows for Purchase RequisitionsUI
- SAP Workflow Tcodes ( Transaction Codes )
- 如何在 SAP BTP 上 手動執行 workflow
- SAP BTP 上 workflow 和 Business Service 的 project 管理Project
- bug solved | This experimental syntax requires enabling xxxUI
- SAP工作流介紹之ABAP Business Workflow介紹
- SAP MM 公司間退貨STO的交貨單PGI報錯 -Purchase order 4500000773 does not -
- SAP 業務技術平臺(BTP) Workflow(工作流)功能介紹
- FSMO(Flexible Single Master Operation)FlexAST
- lib-flexible原始碼解析Flex原始碼
- SAP RETAIL MM42進入商品的銷售檢視系統提示: No basic purchase price relevant...AI
- flexible.js 相容bug修復FlexJS
- Git workflow 詳談Git
- Laravel workflow with database and roleLaravelDatabase
- Serverless Workflow專案Server
- SAP C4C工作流(Workflow)接收方自動決定的一個例子
- flutter的Flexible和 Expanded的區別FlutterFlex
- WorkFlow學習總結
- Alfred之workflow入門Alfred
- Github Action Workflow 實踐Github
- 如何自動完成登入 SAP BTP workflow(工作流) 管理應用 Launchpad 所需的設定
- 【Flutter 元件集錄】Flexible、Expanded 和 Spacer (上篇)Flutter元件Flex
- In-App Purchase 內購丟單、串單處理APP
- git-workflow[工作流]Git
- 微軟workflow foundation介紹微軟
- workflow 之 Prefect 基本用法(qbit)
- 雲音樂中 In-App Purchase 實踐總結篇APP
- ABAP WORKFLOW工作流建立(一)
- Vue使用lib-flexible,將px轉化為remVueFlexREM
- Board designs, FPGA verilog, firmware for TKey, the flexible and open USB security keyFPGAFlex
- 文字格式轉換工具:Text Workflow for macMac
- Laravel 中文文件檢索 Alfred WorkflowLaravelAlfred