AGS Call to GL40.6

I've mentioned before that you can sometimes get around Lawson's "Click Add Again" messages and here's how when sending an AGS call to GL40.6. Include the PT-XMIT=1 value at the beginning of your AGS statement. This works for both MS Add-Ins and the Transaction node in ProcessFlow.

&FC=Add&PT-XMIT=1&GLC-COMPANY=

ProcessFlow SQL Query JDBC directory path

Lawson's documentation states to install the SQL Server .jar files to the wrong directory.
The correct directory for these files is $GENDIR/bpm/jar and not $GENDIR/bpm/jars.

Lawson is going to correct their documentation but I wanted to post the correction here as well.

ProcessFlow Integrator

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.

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.

Updating WorkUnit Variables in ProcessFlow 9

The WF forms no longer exist in LSF 9 and updates to the WF tables have to be done via a WebRun call. This screen shot shows you the settings to use to update the WorkUnit variable form.

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.

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:

Creating one requisition for mutilple locations

My client wanted to key a single requisition to cover an order for 60+ locations and asked me to design a way to do this. After reviewing options, we decided to use Attributes (MX00) to create a list (in fact, multiple lists depending on the locations to ship to) of requesting locations.

For testing purposes I created a list named SL001 and then created a requesting location with the same name (SL001). I then created a unique requester 9075X set up to require no approvals (our requester id's follow the pattern of 9075A, 9075B, etc. associated to their department number).

When requester 9075A entered his requisition he first changed the requesting location to SL001 and when the requisition was released, ProcessFlow routed the requisition through the normal approvals until the last approval was done.

A Branch was then used to check for the "SL" location and when found the flow went through a query to read the SL001 list of locations and created individual requisitions matching the original one for each location (using the requester id 9075X).

The original requisition is rejected but a comment is added to the new requisitions created referencing the original "master" requisition and the userid of the approver.

ProcessFlow Approval Views

If you're using Design Studio, you can use the formlet tool in the Portal Page design to display the requisition (RQ10) form for approval review instead of building an HTML page to display.
However, if you're like my current client you don't want to click around so much to get to the information you want. We went through various designs and finally came up with one they liked.
Stage 1: Create a modified RQ10 and take away buttons, tabs and fields the approver doesn't need.
Stage 2: Use a reformatted RQ10 Header only and use a Data Query to display the line detail.
Stage 3: Use a reformatted RQ10 Header and a TextArea to write information extracted from DME calls and the getattachrec.exe program for comments so that you can display information from multiple tables.

It's like I always say, you are only limited by your imagination (for the most part).

Using Lawson's getattachrec.exe CGI to retrieve your comments

This sample is pulling the display only comments from the PO Header when a button is clicked and alert it.

function BUTTON_OnClick(id, row)
{
if (id!="push10") return true;
{
var vProd = portalWnd.oUserProfile.getAttribute("productline");
s = "/cgi-lawson/getattachrec.exe?_OUT=XML&_PDL=" + vProd;
s += "&_FN=PURCHORDER&_IN=PCRSET1&K1=1"; //Company
s += "&K2=" + lawForm.getFormValue("text6"); //PO Code
s += "&K3=" + lawForm.getFormValue("text4"); //PO Number
s += "&K4=" + lawForm.getFormValue("text5"); //PO Release
s += "&_ATYP=C&_AUDT=O&_OPM=C&_DATA=TRUE&_ECODE=FALSE";
var getCmnt = portalWnd.httpRequest(s);
var Cmntback = getCmnt.xml;
//Manipulate the data you receive back in order pull the actual comment out.
var B = Cmntback.indexOf("AttData")
var E = Cmntback .indexOf("/AttData")
var myComment = Cmntback.substr(B+23,E-B-32)
alert(myComment);
}
return;
}

I had previously listed the PO Header Comment Types and thought this might be useful.
Requisition Header Comment Types
I - Comments to Print on Headers of Internal Documents
Q - Comments to Print on Requisitions
P - Comments to Print on Purchase Orders
T - Comments to Print on a PO as Trailer Comments
L - Comments to Print on Pick Lists
R - Comments to Print on Receiving Documents
O - Requisition Header Display Only Comments
B - Bill to Address Comments
D - Comments to Print on Delivery Tickets
I'm using a modified PO20 form for ProcessFlow PO approvals and my client didn't like the many steps required to add a comment to the PO (which I'm sending to the buyer to explain why their PO was being rejected). I am using the writeattach.exe CGI to add the comment from a Text Area on my form when the user clicks a "Add Comment" button.

if (id=="push11")
{
var vProd = portalWnd.oUserProfile.getAttribute("productline");
var vComm = lawForm.getFormValue("textarea1");
s = "/cgi-lawson/writeattach.exe?_OUT=XML&_PDL=" + vProd;
s += "&_FN=PURCHORDER&_IN=PCRSET1&K1=1";
s += "&K2=" + lawForm.getFormValue("text6");
s += "&K3=" + lawForm.getFormValue("text4");
s += "&K4=" + lawForm.getFormValue("text5");
s += "&_ATYP=C&_AUDT=O";
s +="&_USCH=none&_DATA=TRUE&_OPM=M&_ECODE=FALSE&_ANAM=Approval Comment";
s += "&_ATXT=" + vComm;
alert ("Your comments have been accepted.")
portalWnd.httpRequest(s);
}

The comment types (&_AUDT= ) are:
B – Purchase Order Bill To Address
D – Comment to Print on Delivery Ticket
E – Purchase Order Copy Comments and Errors
I – Comments to Print on Headers on Internal Documents
N – Invoice Comments
O – Purchase Order Header Display Only Comments
P – Comments to Print on Purchase Orders
Q – Comments Pertaining to Vendor Contacts
R – Comments to Print on Receiving Documents
T – Comments to Print on Purchase Orders as Trailer Comments
My current client is implementing 9.0 and I wanted to use some of my previous ProcessFlow solutions for them, but most of my files are 8.03 .flo files.

Lawson does have a program to convert 8.03 flow files to 9.0 but they won't tell you how to use this program unless you've gone through the migration to 9.0 technical training. I haven't taken this training so I had to find a resource who had and was willing to share information.

The following instructions are a variation of Lawson's instructions. You will use the DEV product line in the Perl command instead of the 8.03 product line that Lawson's instructions say to use since if you're implementing 9.0 you won't have an 8.03 product line. Also, you will have to take the .xml files created and re-upload them into Lawson via the ProcessFlow Designer.

Create a directory: mkdir $GENDIR/ug81/803flows and copy your .flo files into that directory.
Change to the migration directory: cd $GENDIR/ug81
Run the flow conversion script:Perl pflowtoxml.pl DEV dir $GENDIR/ug81/803flows >pflowtoxml.log 2>&1

After running, check the pflowtoxml.log file for any conversion errors and the location of the revised files.

This program will write your revised .xml flow files to the pfrepository directory but you will have to transfer them to your workstation and upload them via the ProcessFlow Designer (after making any needed changes) since you're not actually converting to 9.0 and the system won't recognize the flows unless you upload them this way.
In ProcessFlow 9 (this was updated in v 8.1, but I don't know anyone who used 8.1) you no longer have to default the application product line like you did with previous versions using WF00.

The application product line is now a criteria field on your Service so that you can enable your Service for only one product line or for different product lines by copying the Service (this allows connecting it to a different flow file by product line).

If you don't default a product line your Service will work with as many product lines as you've set up to use ProcessFlow. (Some of the enable flags, like with Match Company for cost messages still refer to ProcessFlow as WorkFlow).
If you're using Design Studio to create your ProcessFlow Inbasket displays, you aren't limited to a Formlet, you can use a Data Query.

Here's how to include select criteria from the variables in your flow so that only the data you want will be displayed:

function data0_OnInit()
{
// create new variables and reference the variables from your flow (page.parameters.FLOWVARIABLE)
var myVen=page.parameters.VEN
var myInv=page.parameters.INV
var myItem=page.parameters.ITEM

// data0 = your Data Query name
var dmeObj = page.objects["data0"];

// pass your variables as Select criteria to your Data Query
dmeObj.criteria += "SELECT=VENDOR%3D" + myVen + "%26INVOICE^%3D" + myInv + "%26ITEM^%3D" + myItem
}
When you create a new service for ProcessFlow and want to use the form (for example, PO20) for the XML Inbasket (created via Design Studio) you must have set your variables up with the correct syntax. The Service variables must use underscore characters instead of dashes (PCR_COMPANY & PCR_PO_NUMBER, etc.)

If you don't then Lawson's script to default these values won't work (from the ProcessFlow Admin Guide). Also, a previous version of this sample script works - if fact it was less coding so I don't know why Lawson changed it.

Function portalpage_OnInit()
{
page.addElement("PCR-COMPANY", page.parameters.PCR_COMPANY)
page.addElement("PCR_PO_NUMBER, page.parameters.PCR_PO_NUMBER)
return true;
}