Creating a workflow for z-objects

[ronen_weisz]

Lately, for some reason, I have been doing a lot of workflows for z-objects, I don't know, maybe all the purchase requisitions already have workflows or that it's me. For example: an employee's request for external employment, a request for creating a new material etc. 

The first thing you need to remember is that (as usual) you are not the first person to see the customer requirements, this leads a lot of times to the implementation being based on the module of the person assigned to the task, (excuse me dear PM consultants – you have a great module – it has a tendency to be misused because of that).

Here are a few reasons for the use of standard objects:

A misconception that workflow must be based on a standard object

Change documents

Links to documents (DMS or archive link for example)

A z-table, number range for the storing the data and a screen for displaying it are needed.

And here are reasons not to:

Usually there is no actual link to the standard object created and a lot of user exits/BADIs are required.

Updated to the module during upgrades have unexpected results on your workflow.

Simplify the workflow

The solution depends on the situation (how far are you from the standard object, what development capabilities are available) but lets say a z object solution has being selected.

Creating a new object based on the z-table's key is very simple, if there is a link to a standard object, create it as an attribute, for example an employee's loan request can have the employee object as an attribute – in this case (HCM) there probably will be a 9000 infotype created.

Use the events on the z-object: an employee can request a loan, vacation, new equipment etc. There is no real need to have all these workflows events on the employee or bus1065 objects.

If possible, and a screen is developed to display the data, request that it will be created as a function module and not a program. It's easier to read a return parameter from a function than trying to get data back from an event raised by a program.

If the screen is to be used in the workflow, remember that you need to have control of the buttons of the screen and a 'step' importing parameter will be needed. Common screen options are:

• Start the workflow
• Approve/reject
• Rejection handling (return to approval/delete)
• Display

A return parameter will also be needed or, in case of a program, events will be to be raised based on the decisions.

At the end of the process, usually a standard object will be created, create this as an object returning from the last method of the workflow, this will give the users the option to see the creation workflow from G.O.S of the relevant transition, for example an approved request for a new material should be visible from transaction MM03 if you created the BUS1001006 object in the end.  

P.S

Yes, of course, a class can be used as well. Some might argue that since it's a new workflow it's even better to create a class. Well, use the best option for the situation.