Because the system sends the "Inquire Complete" message back before it actually finishes refreshing the field values displayed (even if it's only a split second) I encountered another issue. I was using the end date from the new record to calculate a salary percentage to display in another field on my form.
Since I was picking up the end date from the previous record this calculation was wrong (unless the user clicked Inquire again). I tried to figure out how to trick the system to perform a secondary inquire and recalculate before the user noticed.
This worked when clicking Next or Previous but I couldn't use it when Inquire was clicked without going into an endless loop.
I finally figured out that what I needed to do was perform a DME (query) against the same records and get my end date from there instead of relying on the form end date value.
It's an extra step but unless Lawson changes their system to not send the message that the inquire was completed until after the form field values are actually refreshed, it's a workaround I will keep handy.
Design Studio On_After_Transaction
I had a need recently to suppress data a entry field on a form which had records that went beyond the first page. What I tried to do first was to check the conditions for when the field should be suppressed after an inquire (or page down) was done.
The down side was that Lawson sends the "Inquiry Complete" before it actually refreshes the page being displayed so my field was suppressed based upon the previous records and not the ones displayed after the page refresh occurs.
My resolution was to use the On_Before_Transaction function instead. When a Page Down fc=="+" occurs I check the last line of the current data and query the next 5 records. If they meet the criteria then I suppress the fields and then allow the page to refresh.
It's an extra step that I shouldn't have to script for but it works.
The down side was that Lawson sends the "Inquiry Complete" before it actually refreshes the page being displayed so my field was suppressed based upon the previous records and not the ones displayed after the page refresh occurs.
My resolution was to use the On_Before_Transaction function instead. When a Page Down fc=="+" occurs I check the last line of the current data and query the next 5 records. If they meet the criteria then I suppress the fields and then allow the page to refresh.
It's an extra step that I shouldn't have to script for but it works.
Requisition Line Approvals
In an earlier post I discussed the possibility of making the Inbasket display more user friendly for Requisition Line Approvals. I was thinking this through for my current client (since this is the method they have chosen) when I realized something.
You can set the requisition to approve by line but you don't actually have to push each line to its own WorkUnit. I know it's a radical idea but since Lawson actually creates a single WorkUnit at the header level by default (with the RQCreateLine Service) and expects you to push each line to either a Grants or non-Grants based line level Service, I wondered what would happen if I didn't actually create a seperate WorkUnit for each line.
You still have to enable the line level approval Services, but you don't have to use them. The Inbasket display I created allows the approver to unrelease and reject individual lines (I still send separate RQ13.2 AGS calls) but I can flow the requisition at the header level.
The maintenance is much cleaner in my opinion.
You can set the requisition to approve by line but you don't actually have to push each line to its own WorkUnit. I know it's a radical idea but since Lawson actually creates a single WorkUnit at the header level by default (with the RQCreateLine Service) and expects you to push each line to either a Grants or non-Grants based line level Service, I wondered what would happen if I didn't actually create a seperate WorkUnit for each line.
You still have to enable the line level approval Services, but you don't have to use them. The Inbasket display I created allows the approver to unrelease and reject individual lines (I still send separate RQ13.2 AGS calls) but I can flow the requisition at the header level.
The maintenance is much cleaner in my opinion.
DME connection error with user lawson
If you're getting one of those annoying DME connection errors with user lawson when running your flow on the server but it works just fine within PF Designer then I have a possible solution for you (I just discovered this for a client).
If the DME has a SELECT statement with an Escape character (%3D for the = character) then replace it with the normal character.
Replace SELECT=STATUS%3D1 with SELECT=STATUS=1
When I did this my DME call worked on the server.
If the DME has a SELECT statement with an Escape character (%3D for the = character) then replace it with the normal character.
Replace SELECT=STATUS%3D1 with SELECT=STATUS=1
When I did this my DME call worked on the server.
ProcessFlow Not Triggering
I've been asked several times recently why ProcessFlow isn't triggering so wanted to give some ProcessFlow 101 things to check:
Does the application form WF01 have the LOGAN value in the Collarborative Commerce Productline field? If not, ProcessFlow won't trigger.
Have you enabled all three of the ProcessFlow Administration Service forms?
Service Definition - Service Criteria Level Definition - Service Process Definition.
If not, ProcessFlow won't trigger.
Have you set up the application prerequisites for your approvals?
PA50 Personnel Action - Use Workflow = Y
RQ04 Requester - Requisition Approval Type - Header using Process Flow
AP00.4 Company - Workflow = Y (and so forth)
If not, ProcessFlow won't trigger.
My favorite recent issue - along with the ProcessFlow Solution Packs being installed, was the WFDATA installation also done?
If not, ProcessFlow won't trigger.
Does the application form WF01 have the LOGAN value in the Collarborative Commerce Productline field? If not, ProcessFlow won't trigger.
Have you enabled all three of the ProcessFlow Administration Service forms?
Service Definition - Service Criteria Level Definition - Service Process Definition.
If not, ProcessFlow won't trigger.
Have you set up the application prerequisites for your approvals?
PA50 Personnel Action - Use Workflow = Y
RQ04 Requester - Requisition Approval Type - Header using Process Flow
AP00.4 Company - Workflow = Y (and so forth)
If not, ProcessFlow won't trigger.
My favorite recent issue - along with the ProcessFlow Solution Packs being installed, was the WFDATA installation also done?
If not, ProcessFlow won't trigger.
Approving Requisition by Line with ProcessFlow
My latest client is only my third to decide to approve requisitions through ProcessFlow by line instead of by header. While I like the concept, I don't like all of the WorkUnits (one for the requisition header and then one for each line to be approved).
I only had last week to work with them on developing this flow so I didn't get to test a theory that I'd like to put in place for this process - a process that would be easier for the approver but much more complicated to program.
In concept the approver should be able to view all of the pending lines on the requisition and then select which to approve, which to reject and which to unrelease; all from one Inbasket form.
After selecting the lines to reject or unrelease the Portal Page script would update RQ13.2 and then for the lines being approved the script would trigger ProcessFlow for the next approval level. (You'd have to program the script to require the approval to be done last.)
This way the number of WorkUnits would be greatly minimized as well as the number of UserAction notification emails. Like I said, it would be easier for the approver but more complicated to program.
I'm willing to give it a try - any takers?
I only had last week to work with them on developing this flow so I didn't get to test a theory that I'd like to put in place for this process - a process that would be easier for the approver but much more complicated to program.
In concept the approver should be able to view all of the pending lines on the requisition and then select which to approve, which to reject and which to unrelease; all from one Inbasket form.
After selecting the lines to reject or unrelease the Portal Page script would update RQ13.2 and then for the lines being approved the script would trigger ProcessFlow for the next approval level. (You'd have to program the script to require the approval to be done last.)
This way the number of WorkUnits would be greatly minimized as well as the number of UserAction notification emails. Like I said, it would be easier for the approver but more complicated to program.
I'm willing to give it a try - any takers?
Subscribe to:
Posts (Atom)