I'm just getting started with ProcessFlow Integrator and I like what I see so far.
My client uses a custom employee evaluation program run from a SQL Server 2005 database and wanted to get completed evaluations and bring them into Lawson for the merit increases. Each employee receives a score of 1 - 6 which relates to their merit pay increase percentage (a score of 3 nets a 3% raise).
By using the SQL Query node from ProcessFlow we were able to connect to this external database [a big thanks goes out to John Henley, the Lawson Guru, for his help on setting this up] and create a Personnel Action (PA52) for the pay change.
We had a bit of difficulty in that Lawson doesn't seem to support the JDBC driver for SQL Server 2005 so we had to use the SQL Server 2000 driver, but the driver worked with 2005 so we were still able to get the data we needed.
Another nice utility, the CustomActivity node, allowed us to run the Move WorkUnits to History job so we didn't have to set up the Perl script for this function.
WF Forms in ProcessFlow 9.x
You know you have to use a WebRun to update the old WF forms in v. 9.x
Here's some of the ones I've used and I thought it would be nice to share them.
The first line is the old WF form, the 2nd line is the WebRun Web Program field value and the 3rd line is the WebRun Post String value.
WF46.1
bpm/queueForm.do
method=Change&workUnit=548&processId=548&activityId=UA22
&displayStatus=8
WF20.1
bpm/workUnitBForm.do
method=Change&workUnit=534&status=4
WF12.4
bpm/xml/userCategoryForm.do
method=Add&id=MZAMBELLI&task=Level5&workCategory=Req Loc&workCategoryValue=10003
WF22.1
bpm/xml/workUnitVariablesForm.do
workUnit=177&variableName=RQH_APPROVAL_VAL&sequenceNumber=12
&variableValue=333&variableType=3&method=Change
See Lawson KB article 556115 (and yes, I list some that Lawson didn't include).
Additional hint: To see the fields available do a method=Inquire on the XML form you're working with.
Here's some of the ones I've used and I thought it would be nice to share them.
The first line is the old WF form, the 2nd line is the WebRun Web Program field value and the 3rd line is the WebRun Post String value.
WF46.1
bpm/queueForm.do
method=Change&workUnit=548&processId=548&activityId=UA22
&displayStatus=8
WF20.1
bpm/workUnitBForm.do
method=Change&workUnit=534&status=4
WF12.4
bpm/xml/userCategoryForm.do
method=Add&id=MZAMBELLI&task=Level5&workCategory=Req Loc&workCategoryValue=10003
WF22.1
bpm/xml/workUnitVariablesForm.do
workUnit=177&variableName=RQH_APPROVAL_VAL&sequenceNumber=12
&variableValue=333&variableType=3&method=Change
See Lawson KB article 556115 (and yes, I list some that Lawson didn't include).
Additional hint: To see the fields available do a method=Inquire on the XML form you're working with.
ProcessFlow AGS call - click Add again!
Have you come across this when you use an AGS call to Add on a form (like GL40.6)? You're asked to click add again but you can't. I found a simple work around that might work for you too.
Instead of using EVT=ADD, change it to EVT=CHG
I won't promise it will work on all forms, but I've used it a couple of times when I've had this come up.
Instead of using EVT=ADD, change it to EVT=CHG
I won't promise it will work on all forms, but I've used it a couple of times when I've had this come up.
Updating WorkUnit Variables in ProcessFlow 9
ProcessFlow Custom Functions
I've mentioned this before but it won't hurt to get a reminder.
You can build your own custom JavaScript functions to be used by ProcessFlow in the Assign node. I have a client who wanted their requisitions approved based upon Company & Acct Unit instead of requesting locations.
They also wanted that requisition reviewed by all Approvers associated to the various company/acct unit combinations on the requisition. This meant that in both level 1 and level 2 of their approval process, all level 1 approvers (and then level 2 approvers) had to approve that requisition.
So each approver has to review the requisition and approve it and then it would move on to the next possible approver at the same level. Once all have approved at level 1 it then repeats this for level 2.
To do this I read through the requisition with a query loop and assign the company/acct unit values to a variable. I then use the Assign node to pass that variable to a custom function which excluded the duplicates and passes that back to another variable.
I then pass that new variable to an Assign node to read the current category filter value for each approver. I also track who has approved thus far and use another custom function to check that the current approver hasn't already approved the requisition under a different company/acct unit combination they may have been set up for.
The custom function needs to be added to the pflow.js file in order to be available to your flow file.
You can build your own custom JavaScript functions to be used by ProcessFlow in the Assign node. I have a client who wanted their requisitions approved based upon Company & Acct Unit instead of requesting locations.
They also wanted that requisition reviewed by all Approvers associated to the various company/acct unit combinations on the requisition. This meant that in both level 1 and level 2 of their approval process, all level 1 approvers (and then level 2 approvers) had to approve that requisition.
So each approver has to review the requisition and approve it and then it would move on to the next possible approver at the same level. Once all have approved at level 1 it then repeats this for level 2.
To do this I read through the requisition with a query loop and assign the company/acct unit values to a variable. I then use the Assign node to pass that variable to a custom function which excluded the duplicates and passes that back to another variable.
I then pass that new variable to an Assign node to read the current category filter value for each approver. I also track who has approved thus far and use another custom function to check that the current approver hasn't already approved the requisition under a different company/acct unit combination they may have been set up for.
The custom function needs to be added to the pflow.js file in order to be available to your flow file.
Releasing PO's with ProcessFlow
I've had several clients recently who've wanted to use ProcessFlow to "Approve" purchase orders. Using Design Studio we removed the "Release" function from PO20 & PO23 and instead added a button to trigger ProcessFlow.
This has worked out very well but (of course) we had a couple of issues to resolve:
In the notice back to the buyer that their PO was approved or not approved we wanted to include the URL back to the PO in question. This required us to "escape" the PO number, release and code string so that the buyer could click the URL link in the email notice.
Using an Assign node, we assigned the following value to the "PO" variable: URLEncoder(PCR_PO_NUMBER+PCR_PO_RELEASE+PCR_PO_CODE) and then we referenced that variable in the URL string: http:///lawson/portal/?_PDL=PROD&_TKN=PO20.1&_HK=0001 (Company 0001 was hard coded).
The 2nd, and more interesting of the issues, was the AGS call to PO22 to perform the Release of the purchase order. The AGS call we originaly designed worked for all of our PO's except for Blanket PO Releases. The sames AGS call that released standard PO's wouldn't work for blanket PO's. We opened a case with Lawson, they duplicated our issue and even wrote up a PT to resolve.
When this got to the developers they came back with a simple, but obscure workaround. We had to reference the PO number, release and code twice (see below) but once we did that, the issue was resolved. Now all PO's release correctly.
AGS call to release PO's via ProcessFlow:
Subscribe to:
Posts (Atom)

