Business Portal to Workflow - a rocky road

Dynamics GP 2013 R2 introduced the new "Workflow" feature that is being used to replace the functionality that used to be in the Business Portal.  Our clients use the Requisition features of Business Portal so the comparable features in GP 2013 R2 were of great interest.


As you may know Business Portal (BP) was designed to run on top of SharePoint.  The migration path for that product is quite painful and ends up in a dead-end - as Microsoft has stopped shipping Business Portal with GP starting in version 2015, due out later this year.  So if a client is currently using Business Portal on GP they have some work to do to figure out if the replacement Workflow features can substitute for what was in BP.


For our BP Requisition users there is some significant loss in making this move.  They use the "multiple times" feature where a user can be in the approval hierarchy more than one time.  That feature allows the requisition creator to choose an alternate approver, which is critical for our clients.  There is no equivalent capability in GP Workflow.  So the clients either need to change their process or find another solution.


As for upgrades we were always stuck in the SharePoint 2007 environment.  This reached the end in GP 2010 and in GP 2013 the clients need to move to SharePoint 2010 (and 2013 is now an option.)  But to get there we have to move from 32-bit SharePoint to 64-bit SharePoint which means we have to start over on a new server.  This also means that while our data will be brought forward none of the essential security permissions in SharePoint will.  Again this will result in substantial pain.


And the worst of making that move is there is no future beyond GP 2013.  So the best option is to look for requisition products in the Third Party community and integrate to GP.


We really like Workflow in GP but very much dislike what Microsoft has done to clients in this migration path.

Range restrictions in Dexterity

Did battle today with range settings in Dex.  I was trying to use a table index for six column filters, two of which allowed ranges.  Yes it's a somewhat hairy screen but I want to give the client good flexibility in filtering what is a voluminous scrolling region.

 

I completely failed on the table index side.  I know I was providing everything correctly but Dex would not honor my ranges.  It would work for the integer columns but not for the text columns.

 

I bailed on that strategy and went with a "range where" clause.  This is an alternative to index ranges that involves building a Transact-SQL where clause - without the actual "WHERE" reserved word.

 

Here is how I did it.

 

I have my filter fields on the top of the window, with the scrolling region below.  I also have a "Redisplay" button in the control area of the form.  The user enters whatever filters they want and click Redisplay and the scrolling region should be restricted based on the criteria.

 

In the script for the Redisplay button I do the following:

 

1. Check if the filter fields are all empty.  If so display the full table in the scroller.
2. Declare a string variable called strwhere to contain the filter conditions.
3. If at least one of the filter fields is provided start to build the conditions.
4. The first condition checks for "if not empty()" on the first field.
5. On subsequent fields I check first to see if strwhere has data and if so add "AND" at the end.
6. For each field I use the physicalname() function to substitute the real column name then add the operator and the value.
7. String fields must be enclosed in single quotes.  This would start with "= '" and end with "'".
8. Where I've allowed a range of values I start with "BETWEEN" and if the "To" value is empty I substitute the "From" field.
9. Integer values can be on the right of the "=" without quotes converted with str().
10. Date values must be converted with str() and embedded with single quotes.

 

At the end of all that I do a "range table <xx> where strwhere" and then fill the scroller from that.


It worked beautifully and took a fraction of the time I wrestled with the index method.  So I'm hooked on range where and moving on.

Dynamics GP Payroll Posting Account gotcha

If your GL distribution for payroll posting is not adding up here is a possible source.

My client was wondering why certain deduction codes were not posting the right GL accounts.  Instead of posting the correct liability account it was posting an expense account.

The problem stems from the way GP posts the payroll accounts when using the "ALL" default

Here is the example.  Say John Smith is in department 12 and job title 204 and has a disability deduction code of 10.  But the payroll clerk noticed that his disability is not posting the liability account.  Instead it is posting an expense account.  Looking at the related payroll posting account assignments reveals the following relevant codes:
 

They thought that GP would code the deduction to account 2100 because it was for code 10.  But GP was actually posting account 5100.

The fix is to assign all three categories as below.


The problem here is GP finds the department/job title combination and uses the ALL code associated with that, instead of finding the deduction code with ALL for department/job title.

In other words they thought GP was behaving one way, when it actually did something different.
Tricky but hopefully this conveys the importance of not assuming!

Dynamics GP 2013 R2 Requisition Workflow

This is the Workflow Approval definition for Purchase Requisitions.

The Managers listed here can be used as targets of the approval steps in the workflow.

 

Although you can have multiple workflows, there can only be one Active workflow at any time.

Workflow consists of one or more Tasks or Approvals.  Tasks are something that is done with the workflow, like assign an account or vendor to it, while an approval is just approving the requisition.

There is no action directly associated with a Task.

 

On completion of an action related to the workflow a number of notifications are available.

(Blue arrow beside the “Send notifications for completed actions” checkbox.)

 

Again a Task is just something that needs to be done to further the workflow of the requisition.

It does not necessarily involve system action.

 

An Approval step is just the user approving the requisition.

There are three options to assigning the approval task:

 

Assigning users is just a matter of entering their network ID:

While a Hierarchy consists of a number of starting options:

And the assignment also has options.

 

The “manager” referenced here is the direct report in Active Directory.

 

Approval can be acted on directly from the notification email.