Question Re: Workflow Functional Specification Document in Technology Q&A

Workflow Functional Specification Document

Former Member — Tue, 17 Jun 2014 20:04:56 GMT

Hi All

I am working on a implementation project which includes Workflows. Right now I am in the process of writing the functional specification document for the Workflows. I am a functional consultant and never worked on workflows.

Can some one provide me what should be included in the functional document , how should the flow be written.

Is there any sample Workflow template anyone can share.

There are 4 places that requires workflows according to my understanding as described below in my requirement:

1. Workflow for corporate users when a notification is created or closed

2. Workflow email, forward a complaint to

Finance Manager

Quality Manager

Plant Managers

3. Workflow for forwarding to an approver, reassign task to someone else

4. Workflow to send remainder emails for open items longer than 30 days

Please provide your insights and neccesary documentation to start

Thanks,

Sai

Re: Workflow Functional Specification Document

ronen_weisz — Tue, 17 Jun 2014 22:47:52 GMT

Re: Workflow Functional Specification Document

Former Member — Wed, 18 Jun 2014 07:27:43 GMT

Hi Sandeep,

From workflow development prospective a developer needs following details in Functional spec:

1.) A flow chart diagram with algorithm which replicates step by step business process of workflow.

2.) Business object for that particular business scenario for which you have to design workflow like for Purchase order business object is BUS2012.

3.) Any standard workflow template if available then you can give reference of that in your FS.

4.) Is there any condition require to trigger the Workflow then that should be available in your FS.

5.) The approver fetching logic should be clear. Like who will be approver of workflow based on which condition.

I think these information are sufficient. Let us know if you need details on any of the point.

BR,

Prakash

Re: Workflow Functional Specification Document

Former Member — Thu, 19 Jun 2014 14:42:17 GMT

Hi Prakash,

Thanks for the response. It gave me a good idea to start with.

I will get back if i am stuck somewhere or need any insight..

Thanks

Re: Workflow Functional Specification Document

Former Member — Thu, 19 Jun 2014 16:55:43 GMT

Hi Prakash,

In my case the

Workflow template is 24500047

Business Object is BUS 2078.

Can i edit the standard business object. I want email triggered at some places esp. when the notification is created and closed. Can you provide the process to edit the business object if it is necessary to do that way.

Further, do i need to do the configuration of the workflow templates.

Please give me your insight.

Thanks

Re: Workflow Functional Specification Document

anjan_paul — Fri, 20 Jun 2014 05:49:18 GMT

HI,

You can't edit standard BO. There is a concept call delegation. Create a sub object, add your method, and delegate it to standard BO

Re: Workflow Functional Specification Document

Former Member — Fri, 20 Jun 2014 06:40:20 GMT

Hi Sandeep,

In functional spec you need to mention the name of Business object(BUS2078) and Workflow template (WS24500047). Developer will check if all the requirements get satisfied with standard once then he / she will use that. If any change require developer will delegate (As Anjan said) the BO.

Regarding the configuration : I think you are working on quality notification workflow. Developer will configure the event linkage of this workflow to triggere. You donot have to config this.

I will suggest during FS writing if you can activate the satndard workflow for testing purpose and check how standard functionality is working that will give you good idea. The Developer have to work if there is some deviation between standard workflow and customer requirement.

BR,

Prakash

Re: Workflow Functional Specification Document

Former Member — Fri, 20 Jun 2014 16:07:55 GMT

Hi Prakash,

Thanks for the response. I will try to simulate by activating the standard workflow and get back if i have any questions.

Regards,

Re: Workflow Functional Specification Document

pokrakam — Sun, 22 Jun 2014 18:27:52 GMT

Hi,


Prakash Jha wrote:

   In functional spec you need to mention the name of Business object(BUS2078) and Workflow template (WS24500047). Developer will check if all the requirements get satisfied with standard once then he / she will use that. If any change require developer will delegate (As Anjan said) the BO.

I would argue that this does not belong in a functional spec. Although a functional consultant with good technical background may write this in as a suggested approach, but it's not their place to mandate what technical objects to use (unless there is a business reason to do so).

A technical expert will decide what objects to use and specify this in the tech spec - I would for example create a ZCL_NOTIFICATION class instead of a BO subtype.

Ronen's blog provides a good overview. A functional spec should describe the business process, what actions require what responses, and what business logic to use for calculating/routing/etc. A technical spec is for technical details.

In my experience I find the most effective way is to work with the workflow expert/developer and build a prototype as part of writing the functional spec. It takes a couple of hours to build a simple workflow with dummy steps (or activate the standard), then you can see what the user would see, and what you write in your functional spec will be far more accurate.

Hope that helps,

Mike

Re: Workflow Functional Specification Document

Former Member — Tue, 01 Jul 2014 14:29:28 GMT

Hi Prakash,

Hope you are doing well.

I have a few questions regarding Organizational Struture and Distribution lists

The business requirement is to when a quality notifications is created, a corrective action has to be taken and task has to be assigned to sales, production and quality managers. Further once the corrective action is submitted for approval to sales director, operations director and quality director an email has to be triggred simultaneously.

We have predefined list depending on plant who can take corrective action and who can approve the corresponding task. Further users should have the option to select who should get the email.

So my problem is, how can we do agent assignment using Organizational Structure for the above scenario. I tried using agent type as Organizational Unit but how do we make sure that only the specific person gets the task and aprroval email.

Also, once we define the distribution list can the user have the option to choose who get the email.

Thanks,

Re: Workflow Functional Specification Document

ronen_weisz — Tue, 01 Jul 2014 21:03:08 GMT

don't use the Organizational Unit as the direct agent type, use a responsibility rule, the responsibilities can have an organizational unit assignment, but it is flexible, you can change the org unit/position/user without having to change the workflow and you can have multiple assignments to one responsibility.

As for selecting the distribution list: if it is a simple selection, you can use a decision task (do you what to sent the mail to distribution list A, B or C), if it is complex you can create a screen and call using an object/class method.

Re: Workflow Functional Specification Document

Former Member — Wed, 02 Jul 2014 06:39:18 GMT

Hi Sandeep,

Little bit confused . As you said :

for approval to sales director, operations director and quality director an email has to be triggred simultaneously.We have predefined list depending on plant who can take corrective action and who can approve the corresponding task. Further users should have the option to select who should get the email.

For Approver Determination:

Case 1: In your scenario approver is not fixed.The approvers get selected based on plant. Try to get link between plant and all the approvers. The easy approch will be to maintain the approvers SAP ID in Z-Table against all the plant and developer will use RULE to fetch approvers from this Z-Table. The structure of Z-Table will be:

PLANT LEVEL OBJID USERID

For one plant 3 entry will be maitained here. LEVEL will help to identify the 3 types of approvers i.e. sales director, operations director and quality director. OBJID value will be US (if SAP ID will maintained in USERID), O (if Org. ID will maintained in USERID), S (if Position will maintained in USERID) etc. Benifit of this approch will be when ever you want to change any approver you have to change corresponding entry in this Z-Table no need to do changes in Workflow (As suggested by Ronen).

Case 2: Now I am confused since you said user can choose next level of approver. So please explain in which scenario Approver will come based on plant and in which scenario user will choose it manually. If user have to choose manually then a screen design is require. From approval screen based on user selection you need to pass the Approver in workflow.

Mail Notification: Extended mail notification functionaity is there. The person who will get work item in his/her SAP inbox for approval they will get mail notification in their external mail ID. All the approvers email id should be maintained along with their SAP ID in T-Code SU01. You Just need to provide mail contents in your FS, workflow developer will put same text in in mail body.

Thanks,

Prakash

Re: Workflow Functional Specification Document

pokrakam — Wed, 02 Jul 2014 09:38:29 GMT


Prakash Jha wrote:

The easy approch will be to maintain the approvers SAP ID in Z-Table against all the plant and developer will use RULE to fetch approvers from this Z-Table.

Why not maintain users in the rule directly? Even easier, no need for extra tables.

Re: Workflow Functional Specification Document

Former Member — Wed, 02 Jul 2014 10:30:53 GMT

Dear Mike,

The easiest way is to create Work Center or ROLE, no major maintence require in that. But according to requirement which Sandeep needs , I think the good approch is to maitain Z-Table. The reason behind that he is still preapring FS of development, today its plant which descides approver tomorrow may be few more parameters also get added, which he can easily achieve by adding new field in table. This is my understanding.

If you know better approch then please provide the same to Sandeep. I considered the FS phase is design phase there will be lots of changes in future in the development.

Cheers,

Prakash

Re: Workflow Functional Specification Document

pokrakam — Wed, 02 Jul 2014 11:07:28 GMT

Hi Prakash,

It's just as easy to add fields to a rule as it is toadding them to a table, so again there is no difference on that part. Responsibilities are more flexible and usually easier to maintain. Hence I would suggest creating a rule with the criteria you need, add relevant responsibilities and assign positions/users.

Since you say this is design phase, that concurs with my earlier statement that this level of detail doesn't necessarily belong in the FS. A functional spec should describe what needs to happen, a technical spec is for the technical implementation which seems to be where this discussion has gone.

Regards,

Mike

Re: Workflow Functional Specification Document

Former Member — Wed, 02 Jul 2014 11:13:04 GMT

Agreed Mike. But it will always helpful from Workflow prospective if Approver determination logic mentioned clearly.

BR,

Prakash

Re: Workflow Functional Specification Document

Former Member — Thu, 03 Jul 2014 14:28:10 GMT

HI Prakash,

Thanks for the detailed response, it helped me a lot.

For Approver Determination:

PLANT LEVEL OBJID USERID

I used the same logic, creating a Z-Table for agents who has to approve the corrective action for taks completed. I was curious if there is a standard way to get this functionality in SAP. I am not sure about the responsibility rule that Mike was mentioning. Can you tell me which approach is a better design.

Sorry for not putting things clealy. There are no levels for approval. Each of them are independent i.e. Sales director , Operations Manager and Quality director should get emails for approval after the Plant Manager, QA, Manager, Sales Coordinator take corrective action and the notification is closed only when all 3 of them approve the corrective action.

The user have to choose manually when the correspondng approver of that plant left the company, long vacation, took a new role etc...

I was thinking about the SO23 distribution list for sending the emails to approvers. Also, how do the emails go to the corresonding approvers of that specific plant unless we explicity specify the email id's associated with that plant. Please clarify.

Thanks,
Sandeep

Re: Workflow Functional Specification Document

pokrakam — Thu, 03 Jul 2014 15:56:12 GMT

Hi Sandeep,


Sandeep Pulavarthy wrote:

 I am not sure about the responsibility rule that Mike was mentioning. Can you tell me which approach is a better design.

I would always recommend responsibilities before Z-tables unless you have a specific reason for a custom table.

In short, tx PFAC you can create a rule based on responsibilities. In the rule, you define container elements (think of these like columns in a Z-Table). For each rule you can then create many responsibilities (similar to rows in your Z-table) based on the container elements you defined.

If you need more details, the SAP help is your friend, and this is covered in the Workflow book (3rd edition coming out very soon). Or post a question here if you get stuck.

For your example: You would define a responsibility rule called Sales Director

Define a container element Plant type WERKS

Then you create a responsibility for Plant=1001, another for Plant = 1002 and so on.

Then you assign users, positions, whatever to the responsibilities. (This is done per-system, i.e. maintained in production).

In workflow, you use the rule as your agent determination in a step and bind the WF container's Plant to the rule's Plant element. The rule will determine the appropriate responsibility and return the agents assigned to it.

There are many ways in which these are superior to custom tables:

- Transaction OOCU_RESP lets a reasonably skilled end user maintain agent assignments - and once they know one rule they know how to do it for ALL responsibility-based workflows

- You can assign users or any org structure element. e.g. if you use positions, then you can just reassign users to the position and all rules where the position appears will automatically route to the new user. Try doing that with 15 workflows and 8 Z-Tables full of userIDs (seen that way too many times!)

- You can assign wildcard elements. e.g. if all French plants start with 20 and have the same director, you can create a single responsibility for plant 20*

- You can have multiple matches and prioritize rules. e.g. if one plant 2004 has a different director, you can have a rule for 2004 with a higher priority than 20*.

- You dont' have to code especially for multiple/mixed matches (can assign 2 users and one position to a responsibilty)

- It's standard SAP

Example:

Rule 1 (Sales Director based on Plant)

-- resp 1 (Plant 1001) -- User ABC

-- resp 2 (Plant 1002) -- User DEF, User GHI

-- resp 3 (Plant 2004) prio 99 -- User JKL, position MNO

-- resp 4 (Plant 20*) prio 00 -- User PQR

Hope that helps,

Mike

Re: Workflow Functional Specification Document

Former Member — Fri, 04 Jul 2014 05:50:41 GMT

Hi Sandeep,

Both ways are expalined in detail here Z-Table as well as Rule. Based on your bsiness requirement take the appropriate one.

But I dont think in your FS this much of detail is require, you just have to mention whom you need in as approver. The developer will choose the logic whether he have to go with Rule or Z-Table or Org object or Role or Distribution list .

Thanks Mike for details.

BR,

Prakash

Re: Workflow Functional Specification Document

Former Member — Mon, 07 Jul 2014 14:13:26 GMT

Thanks for the response Prakash.

I will leave the decision to the developer regarding which approach he want to go with.

Thanks eveyone for the responses. It gave me a great insight.

THanks,