I was asked recently about how to set up a proxy approver for User Level Work tasks. I had previously provided solutions at the Task Level, but not when a UserAction is designated to a User instead of a Task.
What I would do is to create a special “Out of Office” service and flow. The approver would log into an “Out of Office” UI form modified by Design Studio (I usually use WFWK.2) and enter their proxy approver. When they click submit then an OoO service is triggered.
The OoO flow file will add a new Task to that approver and place itself into a UserAction with one available Action – ‘Turn off Out of Office’. Once that is selected the “Out of Office” task is removed and the WorkUnit closed.
The separate approval flow (like for Personnel Actions) would have to query open WorkUnits to see if the pending approver has an open “Out of Office” WorkUnit and read the proxy user id variable. That variable value would be used in the UserAction so both the original approver and the proxy approver are both represented.
The UserAction would also have to be set to “Any Approver Takes Action” so the WorkUnit Metrics records will close correctly once either approver has taken action.
ProcessFlow Escalations
A client recently mentioned to a group of users that they set their approval escalations to 48 hours and had to live with work escalating over the weekend because there was nothing you could do about the hard coded 48 hours.
I stopped him after the meeting and told him that of course you could do something about it - use a variable instead of a number in the UserAction node. The variable could be set to 48 hours by default and if the day of the week was either Thursday or Friday, you could change the variable to 96 hours and thus avoid the weekend escalation.
You would just have to Branch to an Assign prior to routing to the UserAction and check for the day of the week (Sunday =0 to JavaScript).
"Providing Solutions, not Just Answers"
I stopped him after the meeting and told him that of course you could do something about it - use a variable instead of a number in the UserAction node. The variable could be set to 48 hours by default and if the day of the week was either Thursday or Friday, you could change the variable to 96 hours and thus avoid the weekend escalation.
You would just have to Branch to an Assign prior to routing to the UserAction and check for the day of the week (Sunday =0 to JavaScript).
"Providing Solutions, not Just Answers"
More re: On_After_Transaction
Because the system sends the "Inquire Complete" message back before it actually finishes refreshing the field values displayed (even if it's only a split second) I encountered another issue. I was using the end date from the new record to calculate a salary percentage to display in another field on my form.
Since I was picking up the end date from the previous record this calculation was wrong (unless the user clicked Inquire again). I tried to figure out how to trick the system to perform a secondary inquire and recalculate before the user noticed.
This worked when clicking Next or Previous but I couldn't use it when Inquire was clicked without going into an endless loop.
I finally figured out that what I needed to do was perform a DME (query) against the same records and get my end date from there instead of relying on the form end date value.
It's an extra step but unless Lawson changes their system to not send the message that the inquire was completed until after the form field values are actually refreshed, it's a workaround I will keep handy.
Since I was picking up the end date from the previous record this calculation was wrong (unless the user clicked Inquire again). I tried to figure out how to trick the system to perform a secondary inquire and recalculate before the user noticed.
This worked when clicking Next or Previous but I couldn't use it when Inquire was clicked without going into an endless loop.
I finally figured out that what I needed to do was perform a DME (query) against the same records and get my end date from there instead of relying on the form end date value.
It's an extra step but unless Lawson changes their system to not send the message that the inquire was completed until after the form field values are actually refreshed, it's a workaround I will keep handy.
Design Studio On_After_Transaction
I had a need recently to suppress data a entry field on a form which had records that went beyond the first page. What I tried to do first was to check the conditions for when the field should be suppressed after an inquire (or page down) was done.
The down side was that Lawson sends the "Inquiry Complete" before it actually refreshes the page being displayed so my field was suppressed based upon the previous records and not the ones displayed after the page refresh occurs.
My resolution was to use the On_Before_Transaction function instead. When a Page Down fc=="+" occurs I check the last line of the current data and query the next 5 records. If they meet the criteria then I suppress the fields and then allow the page to refresh.
It's an extra step that I shouldn't have to script for but it works.
The down side was that Lawson sends the "Inquiry Complete" before it actually refreshes the page being displayed so my field was suppressed based upon the previous records and not the ones displayed after the page refresh occurs.
My resolution was to use the On_Before_Transaction function instead. When a Page Down fc=="+" occurs I check the last line of the current data and query the next 5 records. If they meet the criteria then I suppress the fields and then allow the page to refresh.
It's an extra step that I shouldn't have to script for but it works.
Requisition Line Approvals
In an earlier post I discussed the possibility of making the Inbasket display more user friendly for Requisition Line Approvals. I was thinking this through for my current client (since this is the method they have chosen) when I realized something.
You can set the requisition to approve by line but you don't actually have to push each line to its own WorkUnit. I know it's a radical idea but since Lawson actually creates a single WorkUnit at the header level by default (with the RQCreateLine Service) and expects you to push each line to either a Grants or non-Grants based line level Service, I wondered what would happen if I didn't actually create a seperate WorkUnit for each line.
You still have to enable the line level approval Services, but you don't have to use them. The Inbasket display I created allows the approver to unrelease and reject individual lines (I still send separate RQ13.2 AGS calls) but I can flow the requisition at the header level.
The maintenance is much cleaner in my opinion.
You can set the requisition to approve by line but you don't actually have to push each line to its own WorkUnit. I know it's a radical idea but since Lawson actually creates a single WorkUnit at the header level by default (with the RQCreateLine Service) and expects you to push each line to either a Grants or non-Grants based line level Service, I wondered what would happen if I didn't actually create a seperate WorkUnit for each line.
You still have to enable the line level approval Services, but you don't have to use them. The Inbasket display I created allows the approver to unrelease and reject individual lines (I still send separate RQ13.2 AGS calls) but I can flow the requisition at the header level.
The maintenance is much cleaner in my opinion.
Subscribe to:
Posts (Atom)