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.
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).
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
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
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
Subscribe to:
Posts (Atom)
