Weird Synchronous Dialog Chain & Substitution Problem

[Bratzler, Loren]

Mark,

To answer your first question:  We do always want the approval task to go to the final approver, if the first approver does not have sufficient dollar authority for the invoice.  If we stopped the approvals with that first approver because they were a sub, it would look, from an audit standpoint, that we were allowing people to approve items that were above their authority level.  The particular case that brought this to light was where the final approver was in the office so they were not expecting the sub to do their work.  They were expecting to get the task in their queue but it never showed up.

When you ask if the "advance with dialog" is maintained on the 2nd approval step, do you mean the second step of my two-step process?  I was wondering if that was necessary or not.  The workflow book mentions that all tasks in a synchronous chain should have the "advance..." option checked.  But I am wondering if the last step of a chain really needs this or not?  That is going to be my first attempt to fix this, is to un-check the "advance..." option on that second step.  But again, it doesn't make sense that this is happening at all because the agents assigned to the tasks are different.  To me, that implies that the system is somehow checking substitution rules and determining that the substitute for the next approver is the same person who processed the last dialog step so go ahead and start the task automatically in that substitute user's queue.

The book also says that synchronous dialog chains do not work with the UWL, but we have several workflows that use this methodology and they all work fine in the UWL.  Is that something that has changed recently?

Loren
________________________________________
From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of Mark Pyc [mark.pyc at gmail.com]
Sent: Tuesday, August 12, 2014 5:35 PM
To: SAP Workflow Users' Group
Subject: Re: Weird Synchronous Dialog Chain & Substitution Problem

G'day Loren,

If the first approver is a substitute for the final approver is a 2nd approval required? Should your logic for determining if a 2nd approval is needed include checks of substitutions?

Also do you have advance with dialog maintained on the 2nd approval step? It prob doesn't make sense to have it set that way.

Have fun,
Mark

Sent from my phone

On 13/08/2014, at 6:36 AM, "Bratzler, Loren" <Loren.Bratzler at nscorp.com<mailto:Loren.Bratzler at nscorp.com>> wrote:

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:

<image001.png>


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:

<image002.png>

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.
<image003.png>

<image004.png>

Has anyone ever run into something like this before?

Loren Bratzler
Norfolk Southern Corporation
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug