Weird Synchronous Dialog Chain & Substitution Problem

Bratzler, Loren Loren.Bratzler at nscorp.com
Tue Aug 12 16:36:17 EDT 2014


I have a weird problem that is occurring with a synchronous dialog chain when there is UWL substitution involved.

For our invoice approval workflow, the approval process is a two-step process.  The first step launches the CHANGE method of the FIPP business object.  Then the second step is a standard user decision step with approve and reject options.  We use the "advance with dialog" option on these two steps so that the user will automatically see the approve and reject buttons when they exit from the CHANGE screen for the business object (making this a synchronous dialog chain).  Our approval process is such that the immediate supervisor of the person who created the invoice is always the first approver of an invoice.  Then if that person does not have the necessary dollar authority, we determine a final approver and send an approval task to that second person.

The issue we are running into occurs if the first approver happens to also be a UWL substitute for the final approver.  When the first approver completes the user decision step (the second step of the two-step dialog chain), the final approver's task is automatically starting in the first approver's inbox.  This is causing the task to be reserved in the first approver's inbox and the final approver never sees the task at all.

I did some testing in our QA system and was able to replicate the issue.  Here is the log when the first approver is not a UWL substitute for the final approver:

[cid:image001.png at 01CFB64A.6EF3F2B0]


And here is the log when the first approver is a UWL substitute for the final approver.  The difference being that the final approver's task is being started automatically for the first approver:

[cid:image002.png at 01CFB64A.6EF3F2B0]

It doesn't make sense that this is happening because the agents assigned to the first approver step (step 8) and the agent assigned to the final approver step (step 36) are not the same.
[cid:image003.png at 01CFB64B.3421DA70]

[cid:image004.png at 01CFB64B.3421DA70]

Has anyone ever run into something like this before?

Loren Bratzler
Norfolk Southern Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20140812/82a5ad5f/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 33932 bytes
Desc: image001.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140812/82a5ad5f/attachment-0004.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 34542 bytes
Desc: image002.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140812/82a5ad5f/attachment-0005.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 20467 bytes
Desc: image003.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140812/82a5ad5f/attachment-0006.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 20354 bytes
Desc: image004.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140812/82a5ad5f/attachment-0007.png


More information about the SAP-WUG mailing list