Display of workitem text in SWIA is not correct

[Former Member]

Dear expert!

We have an issue we haven't managed to figure out, so I'll try to post the question here.

In the project I'm at we have a main workflow and underlying sub workflows. When a documents is scanned in to SAP, it's the WF-BATCH user that is the first agent that has "done something" to the document. When we do reporting from (for example) SWIA, it's the work item <b>name</b> that's displayed as the work item text And not the workitem text.

Now, when I park a document <i>manually</i> from SWUS (and therefore I'm the first agent at the document), the work item <b>text</b> is shown in transaction SWIA. This is how it's supposed to be when the document is parked automaticly as well.

The above mentioned Workflow is new. Previously the customer had a main workflow, with no subworkflows. The first step (to the attestant) was then a single step (TS). In SWIA the work item text was correct. Now (with the new solution) there's a main workflow, and the next step (to the attestant) is a <b>sub</b>workflow. So there's a difference here. Now the problem is (as mentioned) that the work item <b>name</b> is displayed as the work item text in SWIA.

What can we do to display the Work item text as the work item <u>text</u> when we e.g. execute a list from SWIA?

Best regards,

EAJ

[pokrakam]

Hi,

Possibly a language issue - make sure WF-BATCH has the same logon language as the one the texts are maintained in.

The system will always default the WI name for the WI text if either none is supplied or it isn't available in the logon language.

Cheers,

Mike

PS: As an aside - I would suggest to use SWIA quite sparingly, especially in PRD. Mainly because it can do a lot and it's easy to click on the wrong button by mistake (not that I've ever done it

Personally I always stick to SWI1 etc., and use SWIA only if I have a specific reason to.

[Former Member]

Hi. Thank you for the answer. The language of the WF-Batch user is one of the things I have checked before. And the language is okey. I've also checked all the parameters and roles. But everything seems fine.

Best regards,

Eli-A.J

[Former Member]

Hi Eli,

have you tried to make a quick flow with several levels, and a batch run as first step, to see if it is a persistent problem or isolated for the one task alone?

Kind Regards

Mikkel

[Former Member]

Hi. Thank you for the response.

In lack of a test scanner in our test system, we can't test the automatic parking into SAP(!) So I can't test it like you suggest.

But we have tried to change the WF-BATCH user to become a dialog user, so we could log on with it and see if the problem was the user (in transaction SWUS I parked a document with this user). (Offcourse we changed the user back after the test;)) Document parking with the <b>WF-BATCH</b> user gave us the same answer as our ordinary users. So, now we can narrow the problem further down, meaning that we now (probably?) know that the problem comes from automatic parking, and that we might have to take a closer look at the workflow that is <i>before</i> the main workflow.

Best regards,

Eli-A.

[Former Member]

Hi Eli,

Hmm sound to me, like you might not get all the event parameters binded in correctly?!?

You can test on the event using transaction SWUE.

Kind Regards

Mikkel

N.B. Please remember to close the thread, when problem is solved or obsolete.

[Former Member]

Hi Mikkel,

Yes we tested the events yesterday. Seems fine:) The bindings are ok (the flow it selves works perfectly).

Best regards,

Eli

[Former Member]

This problem is not solved yet.

[Former Member]

Bump