The new IPA approval via email function is pretty nice. You simply select this option within the UserAction and whatever Actions you set up are available as buttons within the email notification to your approver.
Of course you do have to select the HTML format and select to send email notifications in the UserAction, but if you set the correct flags, it works great.
The URL behind the action buttons in the email contains an encrypted data string which actually passes your login and password so you don't have to stop at the login page, but it does open a Landmark browser window confirming the action that the user took.
There is a down side - if, for some reason, this email is forwarded to another user and they click the approve button then the action will be recorded as being performed as the original user (since their user id and password is encrypted in the link).
Keep this in mind when you are evaluating the benefit / risk of using this new feature.
Some of you might remember that I played with this a couple of years ago and my solution contained the Action buttons but required the user to log in. My solution was a bit complicated and the interface wasn't as clean.
Infor is looking at adding an option to require the user to log in when they click the Action buttons in the email. This should reduce the security risks that some people might feel is too great.
Design Studio Inbasket - Updateable Form
One of my clients is using ProcessFlow and Design Studio to access custom tables for approving invoices outside of the Lawson application. They defined the custom tables within Lawson's data dictionary so standard DME and AGS calls will work with them.
Because it is outside of Lawson's application, however, they needed to allow "approvers" to make changes to the form values (Department number, Accounting Distributions, PO Number, etc.). What they have been doing is hiding Lawson's standard Inbasket Action buttons and performing the dispatch calls from buttons they added to the Design Studio form.
They did this so they could call the Change function and make sure the data passed the edit checks prior to performing the Approve, Reject, etc. ProcessFlow dispatch call. As you can imagine, this is a bit of customization.
Now that they are looking at moving to Infor Process Automation (formerly LPA) I'm working on recreating some of their custom functionality - still using the S3 custom tables and Design Studio forms.
Rather than hide IPA's Action buttons, I have proposed that the Inbasket form track the field values and perform the Change FC when the user updates each field (with a pop-up alert if the Change Complete - Continue status isn't returned). The user will know right away if there is a problem with their data entry and not have to wait until they attempt to perform the dispatch action.
The draw back? After every Change FC was performed, the cursor would position itself back to the first form field. This is fine if the user is using a hunt and peck method of selecting the fields to update, but not if they're tabbing through the form and changing each field as they go.
So I started tracking which "next field" to go to after making an update and tried adding the Position To by ID function after the calling the Change function. That didn't work.
I tried putting my position to function is different standard functions available to the form, but none of them worked - until I mentioned my problem to my boss, Adam, and he gave me the solution.
He suggested using the textbox's "on focus" function on the first form field and when this field received the focus, check that the next field I wanted to go to was different and then position to that field. A simple and elegent solution that actually works!
Thanks, Adam. Now to convince my client that this is the best option.
Because it is outside of Lawson's application, however, they needed to allow "approvers" to make changes to the form values (Department number, Accounting Distributions, PO Number, etc.). What they have been doing is hiding Lawson's standard Inbasket Action buttons and performing the dispatch calls from buttons they added to the Design Studio form.
They did this so they could call the Change function and make sure the data passed the edit checks prior to performing the Approve, Reject, etc. ProcessFlow dispatch call. As you can imagine, this is a bit of customization.
Now that they are looking at moving to Infor Process Automation (formerly LPA) I'm working on recreating some of their custom functionality - still using the S3 custom tables and Design Studio forms.
Rather than hide IPA's Action buttons, I have proposed that the Inbasket form track the field values and perform the Change FC when the user updates each field (with a pop-up alert if the Change Complete - Continue status isn't returned). The user will know right away if there is a problem with their data entry and not have to wait until they attempt to perform the dispatch action.
The draw back? After every Change FC was performed, the cursor would position itself back to the first form field. This is fine if the user is using a hunt and peck method of selecting the fields to update, but not if they're tabbing through the form and changing each field as they go.
So I started tracking which "next field" to go to after making an update and tried adding the Position To by ID function after the calling the Change function. That didn't work.
I tried putting my position to function is different standard functions available to the form, but none of them worked - until I mentioned my problem to my boss, Adam, and he gave me the solution.
He suggested using the textbox's "on focus" function on the first form field and when this field received the focus, check that the next field I wanted to go to was different and then position to that field. A simple and elegent solution that actually works!
Thanks, Adam. Now to convince my client that this is the best option.
Design Studio - Source Code Changes
I'd had some fun recently creating some cool forms with Design Studio. I've mentioned some of the stuff that I've been able to do, but I thought I'd give a brief list of changes I've made within the Source tab to meet my clients needs.
Custom HR11 form - change the Title
My client didn't want the form's title to display "Employee" so I went into the Source tab, found the Title reference and changed it.
Custom GL41 form - Release button
Due to how a JE with Activities processes, the client didn't want to use Lawson's standard ProcessFlow approval triggers. Now we are going to Submit the form for approval and have ProcessFlow Release the record after the approvals are complete. I found the reference for the Release button within the Source code and changed it so it would display Submit.
//Disp="R" nm="Submit" value="R" nbr="_l19" id="button9" visible="0"
Of course I used the OnBeforeTransaction(fc) function and if fc=="R" I triggered ProcessFlow instead of allowing the Release to take place.
Custom GM65 form - change the Select list values
This client didn't like the descriptions associated to the values within Lawson's standard status list. Rather than delete Lawson's select list and add a new one and then use a lot of scripting to tie them together, I simply found the list within the Source code and changed the display values.
//Disp="1" Tran="1" id="vals1" nbr="_l16" Calculated
//Disp="2" Tran="2" id="vals2" nbr="_l17" Released
//Disp="3" Tran="3" id="vals3" nbr="_l18" Not Used
//Disp="4" Tran="4" id="vals4" nbr="_l19" Certified
Custom WFWK form - change the System value
When I have to create a new form I will sometimes start with one of these little used WFWK .1, .2 or .3 forms as a blank template. In order to include the ability to add a standard Lawson lookup list I change the System associated to my form from "WF" to the system my drop down list is associated to from within the Source.
SYSTEM="GM"
Custom HR11 form - change the Title
My client didn't want the form's title to display "Employee" so I went into the Source tab, found the Title reference and changed it.
Custom GL41 form - Release button
Due to how a JE with Activities processes, the client didn't want to use Lawson's standard ProcessFlow approval triggers. Now we are going to Submit the form for approval and have ProcessFlow Release the record after the approvals are complete. I found the reference for the Release button within the Source code and changed it so it would display Submit.
//Disp="R" nm="Submit" value="R" nbr="_l19" id="button9" visible="0"
Of course I used the OnBeforeTransaction(fc) function and if fc=="R" I triggered ProcessFlow instead of allowing the Release to take place.
Custom GM65 form - change the Select list values
This client didn't like the descriptions associated to the values within Lawson's standard status list. Rather than delete Lawson's select list and add a new one and then use a lot of scripting to tie them together, I simply found the list within the Source code and changed the display values.
//Disp="1" Tran="1" id="vals1" nbr="_l16" Calculated
//Disp="2" Tran="2" id="vals2" nbr="_l17" Released
//Disp="3" Tran="3" id="vals3" nbr="_l18" Not Used
//Disp="4" Tran="4" id="vals4" nbr="_l19" Certified
Custom WFWK form - change the System value
When I have to create a new form I will sometimes start with one of these little used WFWK .1, .2 or .3 forms as a blank template. In order to include the ability to add a standard Lawson lookup list I change the System associated to my form from "WF" to the system my drop down list is associated to from within the Source.
SYSTEM="GM"
Using a Boolean Variable in a Branch
Have you ever created a boolean variable to set whether specific conditions were met in your ProcessFlow and then used a Branch based off of whether it was true or false?
Did you use the condition variable==true?
Did you know that since your variable is either true or false that you could just reference the variable name as your condition and whatever the boolean value was the Branch would interpret that correctly.
So, instead of using variable==true you could just use variable.
Give it a try - it's pretty cool.
Did you use the condition variable==true?
Did you know that since your variable is either true or false that you could just reference the variable name as your condition and whatever the boolean value was the Branch would interpret that correctly.
So, instead of using variable==true you could just use variable.
Give it a try - it's pretty cool.
O Happy Array!
I've recently had to read through a lot of data within ProcessFlow, comparing lists values, etc. and have found that using arrays is a great way to read and compare data.
Most recently I built a flow to review the HR Supervisor records and compare it against ProcessFlow Approvers to make sure the records were in sync. My old method of doing this was to cycle through HRSUPER with a Query while running another Query within the HRSUPER Query loop to see if a matching record existed in PF Admin.
While this did work, I really didn't like running that 2nd Query 900 times! My solution this time around was to run both queries once, saving the values into two different arrays.
I then used a couple of JavaScript Expressions (within an Assign node) to compare my two arrays - one to produce a new array of new Approvers to add and the other to produce a list of Approvers to remove from PF Admin.
I then cycled through these two new arrays with a DataIterator node and used 3 WebRun nodes to add or remove the PF Admin records (User, User Task, User Task Category) as I cycled through the records.
You can do a lot with arrays. I used them recently within Design Studio to assign values from a DME and manipulate and sort the records before presenting them on my form.
O Happy Array!
Most recently I built a flow to review the HR Supervisor records and compare it against ProcessFlow Approvers to make sure the records were in sync. My old method of doing this was to cycle through HRSUPER with a Query while running another Query within the HRSUPER Query loop to see if a matching record existed in PF Admin.
While this did work, I really didn't like running that 2nd Query 900 times! My solution this time around was to run both queries once, saving the values into two different arrays.
I then used a couple of JavaScript Expressions (within an Assign node) to compare my two arrays - one to produce a new array of new Approvers to add and the other to produce a list of Approvers to remove from PF Admin.
I then cycled through these two new arrays with a DataIterator node and used 3 WebRun nodes to add or remove the PF Admin records (User, User Task, User Task Category) as I cycled through the records.
You can do a lot with arrays. I used them recently within Design Studio to assign values from a DME and manipulate and sort the records before presenting them on my form.
O Happy Array!
Change the System Reference in Design Studio
A couple of years ago I referenced how to
Drill Down from another form in Design Studio and I recently had to revisit this option.
When I have to create a custom form, I often just use WFWK.2 as a blank template and build the form, adding the labels, fields and buttons I want to use.
Most of the time this meets my need, unless I need to include a list of employees.
I was able to pull in the Company and Employee fields with their key numbers from HR11 but the select field still wouldn't find any matching employee records. I realized that if I went into the Source of my form and changed the reference to System="HR" that the select field now worked.
Since I'm just using WFWK.2 as a blank template I didn't need to retain the default System="WF" reference.
What a nice work around!
When I have to create a custom form, I often just use WFWK.2 as a blank template and build the form, adding the labels, fields and buttons I want to use.
Most of the time this meets my need, unless I need to include a list of employees.
I was able to pull in the Company and Employee fields with their key numbers from HR11 but the select field still wouldn't find any matching employee records. I realized that if I went into the Source of my form and changed the reference to System="HR" that the select field now worked.
Since I'm just using WFWK.2 as a blank template I didn't need to retain the default System="WF" reference.
What a nice work around!
Subscribe to:
Posts (Atom)