Showing posts with label module workflows.. Show all posts
Showing posts with label module workflows.. Show all posts

Friday, November 23, 2007

Purchase Order and Sales Order Workflow

Purchase Order workflow ( Transaction : ME23N) determines the approval path for the buying organization . It first goes to the buyer, buyer's manager & thereafter based on the cost center & the associated amount, it goes for approval through the Cost Center organization .

i.e,

Buyer ( Requestor in the procurement deptt. of the buying organization)

|
|
v
Procurement Manager
|
|
v
Cost Center org. approval ( based on amount & Sign.Authority level)

Regarding , Sales Order( Transaction: VA01); it is created in the Sales Org of the company & basically governs the pricing structure of the order .The routing of an SO is

Sales Org. ( based on the cost center of the sold item)

|
|
v
Distribution Channel
|
|
v
Division
|
|
v
Reg. Sales office
|
|
v
Sales Group
|
|
v
Sales Person

How to Delete Documents in Workflow?

How to delete documents in workflow that are stuck there and old?

SWWL - Deletes work items

SWW_SARA - Archive work items

You're best advised to use the 'delete logically' functionality:

SWWL will remove them entirely from the SAP database, which could be bad from an audit point of view.

Isn't the real question more as to why those workitems are still in your inbox?

Surely, if the work is no longer needed, the workitem should have completed and hence disappeared.

I'd be inclined to look into that first and foremost.

Is there anyway to undelete work items in SAP workflow after I have logically deleted?

Well not exactly but you can restart the workflow using SWUE, it is same as creating the workflow but good thing is that it will start the point where it has logically deleted.

If I delete a user through su01 then what all are the possible impacts on workflow.

If WF cannot find the user (aka Agent) then it will set the Wf to error status and notify the WF administrator to take action.

I've this work item in inbox. Item 00000 of purchasing document 0010414224 does. How to delete it?

Goto tcode SWWL. Where you can view the list of workitem. From there you can delete your workitem.

Transaction SWWL is fine for an administrator, but is there any "delete" button within business workplace that the users can use to remove workitems from their inbox?

NO! Of course not. It's the whole idea. When a user has an item in his or hers inbox, he/she is expected to execute the item, because it's their job.

Suppose I'm a user. And I have 20 workitems waiting for me to be processed. If I could delete all 20 of them and my manager executes workload analysis, or another tool for checking the workload of users, it would seem that I'm doing a great job. Where as in fact I'm probably destroying master data and upsetting clients.

Delete workflow - RSWWWIDE not working

In development, I have hundreds of unneeded workflow tasks. Running program RSWWWIDE with my userid only displays items I have flagged as deleted. I want to delete the tasks that are in the "READY" state.

The strange thing is, the report has a status parameter with "READY" as one of the options. But regardless of how I execute the report, only the items flagged for deletion appear.

1. Is there a program that will delete the workflows without having to change the status?

2. If not, is there a way to automatically change the status for my tasks to completed? I found a FM which might work, but it requires the task numbers, which I could not find in my inbox.

Workflows that have not been opened, cannot be deleted with RSWWWIDE (even if you put an asterick in the status selection field). You must first open the workflow. You do not have to do anything with it, but it must have been opened prior to deletion.

You can select multiple workflows at once, then hit the execute button. From there, just hit escape to go to the next one.

After all the wf's have been opened the RSWWWIDE program works great!

This is useful in development when you have many unprocessed wf's.

swi14 to Check Statuses of Workflows

I want to use swi14 to check statuses of workflows and let managers what needs to be completed and who has the workflow at the moment.

Problem - there are old workflows that have the "in process" status, but are very old (early 2003) or broken workflows.

My question is how do I get these workflows to a completed status and off this list? I have seen some of the responses to questions like this, but I don't want to delete anything out of the system. I want to keep the workflows as in, only change the status manually.

You can use transaction SWIA to forward the workitem to the person who you want to execute.

This transaction is for processing the workitem as Administrator.

The old unwanted workflows can be Deleted Logically which puts them in Cancelled status. Display the top level work item, use menu path Goto-> Technical workitem display. On the next screen use menu path Edit-> Change. Then click on the 'Delete logically' button.

You can also write an ABAP using the WAPI function modules to cancel Worklfows based on some selection like created date, Id, status etc.

Thanks so much for the info, it worked like a charm!

Finding out the Object Types involved

If I want to develop a workflow for particular scenario , then how should I know the object type used for that scenario?

Is there any standard method to find out the object type involved in the perticular scenario?

Or what can be the work-around ?

Many times the proper object type is not available , so I have to create the object type on my own and assign the events.

Switch the event trace ON (Tcode SWELS), carry out your transaction and view the event log (Tcode SWEL). If there is a standard event then the trace will tell you the name of the object and the event raised. Otherwise create your own object and events and trigger it (them) using FM "SWE_EVENT_CREATE".

Workflow Items Sent To Everyone If Agent Not Determined

We have this problem,whenever a workitem does not determine a agent, it send the workitem to everyone.
This is causing lot of problems.

This is generally a two part issue:

1. At design time, you have defined the task as a 'general task' under the agent assignment.
2. At runtime, when the agent determination routine tries to identify the agent, it cannot. So, because it is a general task, the task is sent to everyone.

To resolve:
1. Instead of making it a general task, try to identify an actual list of 'possible' agents. This could be by positions, userIDs, Org Units, etc. Make this list your possible agents instead of defining it as a general task.

or

2. Make sure your logic for determining the agent always return an agent. If you are using a custom rule, then at the end of the logic check to see if an agent was determined and if not, identify a default agent (like a WF admin or business analyst) that can receive the item and investigate who to properly route it to.

FYI... if you go with option 1 and at runtime the logic fails to determine an agent, then an error message is sent to the WF admin instead of the task being sent to everyone.

Which Agent did execute the task in the Inbox?

Which FW system field does contain the agent, whom has executed a task in her inbox ?
If one of the agents executes task number 1 in her inbox, which system field do I have to use in task number 2 to find which agents did the thing ?

Make a workflow container for Actual Agent of type WFSYST-ACT_AGENT

and then in task 1 do the binding from task container to workflow container for actual agent.

This container then you can use in your next task to see who was the previous agent

Blog Archive