Process status and business status

[Christian_Gaert]

Hi all,

I have "inherited" some existing "processes and forms". After approval their business status changes to "approved" and after the workflow is completed the process status changes to "completed".

My own built processes and forms don't do that. Business status remains "processed" and after workflow is completed process status remains "in process".

I have compared them carefully, but do not see any difference or rather find out, where and how my predecessors realized the status changes.

By research and googling I found SPRO activity "Maintain business status". Is this the correct way to customize status changes? But, on the other hand, these tables are empty in my customers system. So my predecessors must have found a different way.

Can anybody help me?

Thanks in advance.

Best regards

Chris

[Christian_Gaert]

Hi all, I still have not found an solution for this. Any more ideas? I appreciate your help.

[Christian_Gaert]

Hi Christopher,

thanks for you answer and your help.

I have just realized, that the business status is OK, more specifically not as relevant for the customer as the process status. After completing a process and its workflow the *process status* (table T5ASRPROCESSES, field status) is still "STARTED". We expect it to be "COMPLETED". Do you know where and how this status is set by the framework.

As already mentioned, it works for all the customer processes of my predecessors, but won't work for both of my own processes.

Differences between them (which may cause the different behaviour):

Processes of my predecessors: They are for Application "PD" and Objekt-Type "O" in Table T5ASRPROCESSES.

My own processes are for application "PA" and Objekt-Type "P".

Hope you can help.

Thanks in advance!

Best regards

Chris

[ChrisSolomon]

Are you sure you have PROCSTATE in your bindings as a parameter returned by each standard task so you have the value? And importantly and often overlooked, are you sure the "Program Exits" has CL_HRASR00_POBJ_WF_EXIT set on it?

[Christian_Gaert]

Both yes!

PROCSTATE is returned to check for approval (for example).

Screenshots:

https://scheergmbh-my.sharepoint.com/:o:/g/personal/christian_gaertner_scheer-group_com/EksC-UupwehL...

I would really appreciate, if you had more suggestions.

[ChrisSolomon]

Process Status and Business Status are two different things.

Process Status is "hard set" by SAP with statuses like "processed", "resent", "back", "rejected", etc. that is used by the framework. This process status (value PROCSTATE) is often checked in workflow to direct routing. For example, if you have a workflow "condition" that checked "PROCSTATE = BACK" would mean you were checking if it was sent "back to author" by the user or that "PROCSTATE = PROCESSED" means that it was submitted by the user to go to next step.

Business Status on the other hand can be thought of as a "free form" status that YOU can configure and set as you like. Like PROCSTATE, you can set it on the "bindings" of a workflow step and then it will show up as that status to the user. For example, you may want a business status called "Executive Approval". You would configure that in SPRO as a "business status" option and then use it in your workflow binding for whatever step you want to call "Executive Approval". Then when someone was viewing "open processes" or "search processes" to see the status of the process and it is on that step, they will see business status as "Executive Approval" whereas the process status may be something like "APPROVED".

Now, to answer your bigger question....the person before you SHOULD have set up the statuses in SPRO and then used those in workflow bindings. (kind of like setting up a key/value pair so the "key" is used in workflow binding in case the "Value" ever changes it will change in all places for you) However, they may have set them (hardcoded strings) directly in the workflow binding...which is lazy, bad and I hope they did not do that to you! (haha).

Hope this makes sense.