In a previous posting I mentioned modifying the pflow.js file in order to add a custom JavaScript function for use within your flow (http://consultdavidw.blogspot.com/2007/07/processflow-custom-functions.html) but with ProcessFlow Designer 9.x you can now add a JavaScript Function within your flow.
Within the Assign node properties, click the Add JavaScript button and the JavaScript Expression Builder will open allowing you to add your custom function.
Of course the advantage to using pflow.js for your JavaScript functions is that they're available to all of your flows but if you just want a quick custom function then this new feature may be the way to go.
PO Vendor Agreement Notify
Just in case you, like another one of my clients, wants to use this ProcessFlow Service to notify the Agreement Administrator that the PO's released against a Vendor Agreement have exceeded the notification percent on the PO25 setup form - you will need to make sure that ProcessFlow Administration (menu.do) has the Form and Form Field Definitions defined for the PO25.1 form.
For some reason, like for the Invoice Approval AP26.1 form, this form definition is missing and this Service won't work without it.
For some reason, like for the Invoice Approval AP26.1 form, this form definition is missing and this Service won't work without it.
LBI Reporting Admin User/Group Rights
I don't usually post LBI tips but my latest client had an issue with User/Group Rights on a report that bothered me. We set up the Elements, Structures and Rights correctly but when we tried to access the report we got an error saying no rights existed for the user.
What we found (with help from Lawson support) was that the Start Date for the Right had to pre-date the oldest historical instance of the report. We Published a report on the 15th and created the Right (with a start date of the 15th). We had to back date the Right's start date to the 14th for the user to be able to view the report.
By the way, if you Burst a report with a Schedule, all users of that report have to have User/Group Rights set up correctly or the Bursting process won't work. No historical instances will be created and no Email notifications will be sent out.
What we found (with help from Lawson support) was that the Start Date for the Right had to pre-date the oldest historical instance of the report. We Published a report on the 15th and created the Right (with a start date of the 15th). We had to back date the Right's start date to the 14th for the user to be able to view the report.
By the way, if you Burst a report with a Schedule, all users of that report have to have User/Group Rights set up correctly or the Bursting process won't work. No historical instances will be created and no Email notifications will be sent out.
ProcessFlow 9 Invoice Approval
I was surprised that I hadn't done an Invoice Approval Flow in LSF9 until now and so didn't know about a potential problem. The WorkUnit created for the Invoice Approval wouldn't update beyond "Ready to Progess" until I added the AP26.1 & J-AP26.1 Form & Field Definitions.
This problem existed in 8.03 but the AP30.2 & J-AP30.2 definitions resolved that issue. Apparently in ProcessFlow 9 you have to also add the AP26 definitions and set them up exactly like the AP30.2 definitions.
Once this was done the next invoice I released was processed as expected in ProcessFlow. The ones that hadn't updated I went ahead and Released on the WorkUnit form and they processed.
This problem existed in 8.03 but the AP30.2 & J-AP30.2 definitions resolved that issue. Apparently in ProcessFlow 9 you have to also add the AP26 definitions and set them up exactly like the AP30.2 definitions.
Once this was done the next invoice I released was processed as expected in ProcessFlow. The ones that hadn't updated I went ahead and Released on the WorkUnit form and they processed.
Design Studio JavaScript
I have been asked how I learned JavaScript for use within Design Studio (and with some limitations within ProcessFlow) and I admit I steal a lot of code from other people. I do have a JavaScript for Dummies book but my main source for JavaScript help is http://www.w3schools.com/js/
Lawson does provide some examples in the Design Studio Reference Guide but not usually for what I need to do. For Portal Page elements a good source of information is the DOM reference within Design Studio - Tools - Objects Viewer
DOM stands for Document Object Model and within Design Studio can be used to figure out how the objects within the Portal Page work.
Lawson does provide some examples in the Design Studio Reference Guide but not usually for what I need to do. For Portal Page elements a good source of information is the DOM reference within Design Studio - Tools - Objects Viewer
DOM stands for Document Object Model and within Design Studio can be used to figure out how the objects within the Portal Page work.
Getting an AGS Call to Work
I recently received an email from a new ProcessFlow user asking how to get an AGS call to work to update PA42 with the correct status for a job requisition approval flow. She sent me her current AGS call and I compared it to one I knew worked. The only thing missing was the &FROM-WORKFLOW=Y section.
I get questions like this from time to time about why an AGS call from ProcessFlow (or Design Studio) doesn't work and the first question I usually ask is can you perform the update on the actual form in Portal? If they can then it's not a security issue (it often is even for the "Lawson" user).
Now comes the debugging part - what is happening on the Portal form that isn't included in the AGS call? I usually start with the API Builder tool to test my AGS call. You'd be surprised how often the results let you know that a field is required that you left out.
Sometimes though it's not obvious and you just have to keep adding fields until you get to a complete AGS call (and sometimes the additional fields don't make sense to you).
However another option is to use a tool like Fiddler to debug the working AGS call from your Portal form. Once you see what Lawson sends itself in the way of an AGS call you can usually duplicate it to get your ProcessFlow or Design Studio AGS call working correctly.
I get questions like this from time to time about why an AGS call from ProcessFlow (or Design Studio) doesn't work and the first question I usually ask is can you perform the update on the actual form in Portal? If they can then it's not a security issue (it often is even for the "Lawson" user).
Now comes the debugging part - what is happening on the Portal form that isn't included in the AGS call? I usually start with the API Builder tool to test my AGS call. You'd be surprised how often the results let you know that a field is required that you left out.
Sometimes though it's not obvious and you just have to keep adding fields until you get to a complete AGS call (and sometimes the additional fields don't make sense to you).
However another option is to use a tool like Fiddler to debug the working AGS call from your Portal form. Once you see what Lawson sends itself in the way of an AGS call you can usually duplicate it to get your ProcessFlow or Design Studio AGS call working correctly.
Automating Supervisor Task setup in ProcessFlow
A question was posted on John Henley's LawsonGuru ProcessFlow Forum related to using the HR Supervisor structure to automate the setting up the the users, tasks and filtering in ProcessFlow administration.
I did this for a client recently so posted a reply on how to update the LSF9 WF forms related to these settings. Here are the values to use in the WebRun nodes for updating each of the forms.
User Proflie Update
Web Program: bpm/xml/userProfileForm.do
Post String: method=Add&id=UserId&filterCategory=Y
User Task Update:
Web Program: bpm/xml/userTaskForm.do
Post String: method=Add&id=UserId&task=Supervisor&filterCategory=Y
User Category Update:
Web Program: bpm/xml/userCategoryForm.do
Post String: method=Add&id=UserId&task=Supervisor&workCategory=Supervisor&workCategoryValue=HRSUPER_CODE
(I had to leave off the angle brackets on the variable references)
I did this for a client recently so posted a reply on how to update the LSF9 WF forms related to these settings. Here are the values to use in the WebRun nodes for updating each of the forms.
User Proflie Update
Web Program: bpm/xml/userProfileForm.do
Post String: method=Add&id=UserId&filterCategory=Y
User Task Update:
Web Program: bpm/xml/userTaskForm.do
Post String: method=Add&id=UserId&task=Supervisor&filterCategory=Y
User Category Update:
Web Program: bpm/xml/userCategoryForm.do
Post String: method=Add&id=UserId&task=Supervisor&workCategory=Supervisor&workCategoryValue=HRSUPER_CODE
(I had to leave off the angle brackets on the variable references)
Design Studio - Drill down from another form
A client wanted to customize their AR09-Customer Group Address form so that they could add the AR10-Customer record at the same time. To do this we needed to add ten fields from AR10 onto the AR09 form.
Adding ten textbox fields to AR09 and then including an AGS call to add the AR10 record (after the AR09 Add button was clicked) wasn't too difficult. I didn't need to store those values, just have the textbox fields available on the form.
What made this interesting was the need to drill down on those new fields to look up the values available from the AR10 form. At first I 'borrowed' a technique I'd seen another consultant use - a custom search window with a DME call to return the values and allow the user to select the one they wanted.
This wasn't practical however when there were 1000's of records to page through so I decided to experiment and try to duplicate Lawson's drill down function on these textbox fields.
I discovered that if I added 'keynbr' and 'hsel' values to the Source code for each of the textbox fields that I could add Lawson's drill down function to them.
I created a QuickPaint of the AR10 form to look up the keynbr values for each of the fields I wanted to include on AR09 and then added those values to my textbox fields.
For example for the Default Code field I added keynbr="M4" & hsel="1" to the Source line for the "text29" textbox field and the drill down was now available. For each of the other fields I added the correct keynbr and the hsel="1" value as well.
I could now drill down for values from a different form than the one I was viewing.
Adding ten textbox fields to AR09 and then including an AGS call to add the AR10 record (after the AR09 Add button was clicked) wasn't too difficult. I didn't need to store those values, just have the textbox fields available on the form.
What made this interesting was the need to drill down on those new fields to look up the values available from the AR10 form. At first I 'borrowed' a technique I'd seen another consultant use - a custom search window with a DME call to return the values and allow the user to select the one they wanted.
This wasn't practical however when there were 1000's of records to page through so I decided to experiment and try to duplicate Lawson's drill down function on these textbox fields.
I discovered that if I added 'keynbr' and 'hsel' values to the Source code for each of the textbox fields that I could add Lawson's drill down function to them.
I created a QuickPaint of the AR10 form to look up the keynbr values for each of the fields I wanted to include on AR09 and then added those values to my textbox fields.
For example for the Default Code field I added keynbr="M4" & hsel="1" to the Source line for the "text29" textbox field and the drill down was now available. For each of the other fields I added the correct keynbr and the hsel="1" value as well.
I could now drill down for values from a different form than the one I was viewing.
A quick way to handle arrays in ProcessFlow
My client has an external system for their merit reviews and is passing a delimited file to Lawson for ProcessFlow to add the PA26 record and to kick off a Merit Personnel Action for the merit pay change.
The file looks something like this:
Record Type|Company|Employee|Scheduled Review Date|Actual Review Date|Review Score|Merit Increase Percent|Supervisor
A|100|53059|20080601|20080701|3|3.5|90006
Record Type|Company|Employee|Scheduled Review Date|Actual Review Date|Review Score|Merit Increase Percent|Supervisor
A|100|53059|20080601|20080701|3|3.5|90006
I'm using the DataIterator node to read the lines from the file and then an Assign node to parse the line to different variables.
Within the Assign node the JavaScript Expression looks like this:
ary = new Array(); ary = NewMerit_outputData.split("|"); ary[0]
so the first variable gets the value "A"
The second variable gets the value of "100" with this JavaScript Expression:
ary = new Array(); ary = NewMerit_outputData.split("|"); ary[1]
NewMerit_outputData is the value of the line being read by the DataIterator.You notice this is basically rebuilding the array for each variable.
Here are the steps this expression takes:
Define the variable 'ary' as a new array
Read the value of the input line and split it into the array
Read the value of the array at position #
The last expression in the JavaScript Expression is what is assigned to the variable. I have in the past modified the pflow.js file to perform a similar function but that's not always practical so I decided to try this first.
HTML Inbasket Display Permission Denied
If your network security is tight then you may get a "Permission Denied" error when trying to view a display exec file in your ProcessFlow Inbasket.
We were able to resolve this for a couple of clients by adding the Lawson Server URL to the Trusted Sites in Internet Explorer and by checking the "Allow active content to run in files on My Computer" box on the Tools - Advanced Tab.
We were able to resolve this for a couple of clients by adding the Lawson Server URL to the Trusted Sites in Internet Explorer and by checking the "Allow active content to run in files on My Computer" box on the Tools - Advanced Tab.
WorkUnit Messages
Do you want to add or delete messages within the Inbasket display for your WorkUnit?
I personally don't like the System added Mailmsg messages that are created for Personnel Actions and wanted to figure out how to delete them so the user would know that if a message existed that it was added by another user.
Use a WebRun like this to Add or Delete
UPDTACTION=A to add a message
UPDTACTION=D to delete a message [Note the %20 used for spacing]
I personally don't like the System added Mailmsg messages that are created for Personnel Actions and wanted to figure out how to delete them so the user would know that if a message existed that it was added by another user.
Use a WebRun like this to Add or Delete
UPDTACTION=A to add a message
UPDTACTION=D to delete a message [Note the %20 used for spacing]
Email Inbasket Dispatch
By referencing two of my previous posts - Email HTML Content and Inbasket Action I was able to design the email below so that approvers can view and select the Action they want to take on a ProcessFlow task.
Once the Approve or Reject action is selected a browser window will open confirming the action taken (the user may have to enter their Lawson userid and password).
Once the Approve or Reject action is selected a browser window will open confirming the action taken (the user may have to enter their Lawson userid and password).
Design Studio Portal Page DME
Have you used the Checkbox on your Portal page DME to allow users to select records? A recent client asked me to design a portal page that would display PO agreements that are going to expire during the current month and allow users to select which ones to extend an additional month.
That was fairly easy to do until they asked me to include a button that would allow them to select all of the displayed records. After playing a bit, here's what I came up with.
That was fairly easy to do until they asked me to include a button that would allow them to select all of the displayed records. After playing a bit, here's what I came up with.
Email HTML Content
Number of WorkUnits Displayed
Thanks to Jeff Bolding for bringing this to my attention. If you would like to display more than the standard 10 WorkUnits in your Inbasket you can Add a User Preference value (yes, you have to do this for each user).
You can use always create a flow to Query all of your Users and a WebRun to add this setting to each one:
Web Program: bpm/userPrefForm.do
Post String: method=Add&id=davidwil&systemName=INBASKET&fieldName=NBRWORKUNITS&description=Number of WorkUnits Displayed&fieldValue=20
Inbasket Action
I've had a couple of clients who were reviewing lines of items (requisition or invoice cost messages) and wanted to work individual lines by exception (reject line 3 of 20) but then take the same action for the remaining lines (approve).
I've done this before by processing the action for all of the remaining lines and then closing the remaining open WorkUnits but if you have another level of approval needed then you have to pass those lines of items to another flow... or you can do the following:
Use a Query to get the remaining WorkUnit, Process Id and UA Id's and then use a WebRun to send the Action to the remaining lines. Using this method is a lot easier.
Web program: bpm/Inbasket
Post String:
FUNCTION=dispatch&WORKUNIT=133&TASK=Level1&APPRODLINE=LAW9WRK&RDUSER=lawson&PROCID=133&PROCNAME=rqapproval_V04&ACTID=UA112&ACTNAME=Level1&ACTION=Approve
I've done this before by processing the action for all of the remaining lines and then closing the remaining open WorkUnits but if you have another level of approval needed then you have to pass those lines of items to another flow... or you can do the following:
Use a Query to get the remaining WorkUnit, Process Id and UA Id's and then use a WebRun to send the Action to the remaining lines. Using this method is a lot easier.
Web program: bpm/Inbasket
Post String:
FUNCTION=dispatch&WORKUNIT=133&TASK=Level1&APPRODLINE=LAW9WRK&RDUSER=lawson&PROCID=133&PROCNAME=rqapproval_V04&ACTID=UA112&ACTNAME=Level1&ACTION=Approve
ProcessFlow Admin for non-PF people
My client doesn't have a ProcessFlow Admin yet so they needed a way for Purchasing to update the Approver setup without going into the ProcessFlow Admin Tool.
We modified the WFWK.2 form to make it easier to submit one of two flows to either replace an Approver or to add vacation coverage for an Approver.
In one the user can enter the Id of an Approver who is gone and the Id of the person replacing them. The flow will look up all of the Tasks of the old approver and the category filtering for each task and delete these from them and add them to the new approver. The flow also updates Lawson Security (Resource Update node) with the email of the new approver and sets the WFUser flag to "1" so the Inbasket will display.
The 2nd option is for vacation coverage. The user will enter the Id of the person going on vacation and the person covering for them. The flow will build the Task/Category Filter as needed for the coverage approver with the start and stop dates of the vacationer.
If, however, the coverage approver is already an approver then you know that you can't add the same Task a 2nd time (if the Approver is "Level1" you can't add a 2nd "Level1" with start and stop dates). To account for this we built the flow so that it would add the category filter items to the existing ones and create a new "Vacation" Inbasket Task.
Once the vacationing approver is back the coverage approver will go into this Vacation Inbasket and select "End Coverage". The flow will then remove the category filter items from their existing ones and remove the Vacation Task from their Inbasket.
We modified the WFWK.2 form to make it easier to submit one of two flows to either replace an Approver or to add vacation coverage for an Approver.
In one the user can enter the Id of an Approver who is gone and the Id of the person replacing them. The flow will look up all of the Tasks of the old approver and the category filtering for each task and delete these from them and add them to the new approver. The flow also updates Lawson Security (Resource Update node) with the email of the new approver and sets the WFUser flag to "1" so the Inbasket will display.
The 2nd option is for vacation coverage. The user will enter the Id of the person going on vacation and the person covering for them. The flow will build the Task/Category Filter as needed for the coverage approver with the start and stop dates of the vacationer.
If, however, the coverage approver is already an approver then you know that you can't add the same Task a 2nd time (if the Approver is "Level1" you can't add a 2nd "Level1" with start and stop dates). To account for this we built the flow so that it would add the category filter items to the existing ones and create a new "Vacation" Inbasket Task.
Once the vacationing approver is back the coverage approver will go into this Vacation Inbasket and select "End Coverage". The flow will then remove the category filter items from their existing ones and remove the Vacation Task from their Inbasket.
Requisition Approval - Skip Levels
One of my clients wanted 6 approval levels but didn't have 6 approvers in each approval path. That wasn't too difficult to design in ProcessFlow; we simply looked up whether or not an approver was assigned at each level and skipped it when no one was assigned to it.
We had a further challenge when we realized that several approvers were also requesters. We didn't want the requester/approver's requisition to have to be approved at a level below (or by) the requester so we checked first whether a requester was an approver and at what level. We then skipped past that level to the next level up.
We then had to account for those levels we skipped and the authority limits of the approvers.
For example, if a requisition was approved at the first level but there wasn't a 2nd level we had to track the "approved at" level to determine whether or not the requisition needed to go to the 3rd level. If the requisition's value exceeds the level 1 approver but not the level 2 approver it would still go to the level 3 approver since no one was assigned to level 2. If however the requisition fell within the level 1 approver's authority limit then no other approval would be required.
We had a further challenge when we realized that several approvers were also requesters. We didn't want the requester/approver's requisition to have to be approved at a level below (or by) the requester so we checked first whether a requester was an approver and at what level. We then skipped past that level to the next level up.
We then had to account for those levels we skipped and the authority limits of the approvers.
For example, if a requisition was approved at the first level but there wasn't a 2nd level we had to track the "approved at" level to determine whether or not the requisition needed to go to the 3rd level. If the requisition's value exceeds the level 1 approver but not the level 2 approver it would still go to the level 3 approver since no one was assigned to level 2. If however the requisition fell within the level 1 approver's authority limit then no other approval would be required.
Subscribe to:
Posts (Atom)