This is the translated version of this SAP Blog.
There is a common requierment to impliment work flow. That’s “差戻し”, sashimodoshi.
In Japan, it’s generally defined as the following statement.
“Returning a submitted document or cases to previous state.” (Reference: Weblio Jisho, Japanese)
You might think it’s “Rejecting”. But, In the contetxt of Workflow in Japan, there is clear difference betwen “Sashimodoshi” and “Rejecting”. Because “Rejecting” means to contunie to end of process, and doesn’t step it back to previous states or steps.
In the blog, I’d like to explain some technical points to impliment “Sashimodoshi” on SAP Build Process Automation. (as of 01.May.2025)
2 Technical Points for Implementation in SAP Build Process Automation
The simplest implementation of “Sashimodoshi” in SAP Build Process Automation is as follows:
The technical points of this implementation are the following two:
Configurating “Sashimodoshi” using “Go to step” function.Managing context data using “custom variables”
I will explain each of these two points in following sections.
Point 1: Configurating “Sashimodoshi” using “Go to step” function
In “Sashimodoshi”, it is necessary to define a process that returns to the previous task, contrary to the normal process flow. To implement this in SAP Build Process Automation, add a “Go to step” function at the step following the rejected “revision form.”
The key point here is to set the “Go to step” function, and set “approve form” as the step following the “revision form” in the function. This allows to enable the process to return to the previous step, and the requester can revise it, so the approver can review the corrections again and decide whether to approve it or not.
Point 2: Managing context data using “custom variables”
The next challenge is how to implement data changes within each form, such as the “approve form” and “revision form.” The key point is the use of custom variables and scripts. This is implemented through the following steps:
Step 1: Create custom variables and set the values of context variables there.
Step 2: Set the custom variables to the relevant items in each form.
Step 3: Use a script to assign the values of the items in the “revision form” to the custom variables. (The script should be added after the “revision form” and before the “go to step.”)
Why are these steps necessary? It is because the script function in SAP Build Process Automation has a limitation that prevents updating the values of context variables directly. The context variables affected are those starting with $.context (excluding custom), $.info, and $.usertasks. For more details, please refer to SAP Help.
Summary
In this blog, I introduced one way implement the Japanese common workflow requirement of “Sashimodoshi” in SAP Build Process Automation. If any experts reading this have other more efficient ways, I would appreciate it if you could share them in the comments section below. Thanks!
This is the translated version of this SAP Blog.There is a common requierment to impliment work flow. That’s “差戻し”, sashimodoshi.In Japan, it’s generally defined as the following statement. “Returning a submitted document or cases to previous state.” (Reference: Weblio Jisho, Japanese) You might think it’s “Rejecting”. But, In the contetxt of Workflow in Japan, there is clear difference betwen “Sashimodoshi” and “Rejecting”. Because “Rejecting” means to contunie to end of process, and doesn’t step it back to previous states or steps.In the blog, I’d like to explain some technical points to impliment “Sashimodoshi” on SAP Build Process Automation. (as of 01.May.2025) 2 Technical Points for Implementation in SAP Build Process AutomationThe simplest implementation of “Sashimodoshi” in SAP Build Process Automation is as follows: The technical points of this implementation are the following two:Configurating “Sashimodoshi” using “Go to step” function.Managing context data using “custom variables”I will explain each of these two points in following sections. Point 1: Configurating “Sashimodoshi” using “Go to step” functionIn “Sashimodoshi”, it is necessary to define a process that returns to the previous task, contrary to the normal process flow. To implement this in SAP Build Process Automation, add a “Go to step” function at the step following the rejected “revision form.” The key point here is to set the “Go to step” function, and set “approve form” as the step following the “revision form” in the function. This allows to enable the process to return to the previous step, and the requester can revise it, so the approver can review the corrections again and decide whether to approve it or not. Point 2: Managing context data using “custom variables”The next challenge is how to implement data changes within each form, such as the “approve form” and “revision form.” The key point is the use of custom variables and scripts. This is implemented through the following steps:Step 1: Create custom variables and set the values of context variables there. Step 2: Set the custom variables to the relevant items in each form. Step 3: Use a script to assign the values of the items in the “revision form” to the custom variables. (The script should be added after the “revision form” and before the “go to step.”) Why are these steps necessary? It is because the script function in SAP Build Process Automation has a limitation that prevents updating the values of context variables directly. The context variables affected are those starting with $.context (excluding custom), $.info, and $.usertasks. For more details, please refer to SAP Help. SummaryIn this blog, I introduced one way implement the Japanese common workflow requirement of “Sashimodoshi” in SAP Build Process Automation. If any experts reading this have other more efficient ways, I would appreciate it if you could share them in the comments section below. Thanks! Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
