If you’ve heard any of my ‘soapbox’ special discussions recently, you know that I am a huge fan of the enhancements flooding into Microsoft Dynamics GP.  In particular, I love to explore the workflow functionality!
Today I was asked a great question about controls involving turning a requisition into a PO.  At first, I was thinking that workflow handled this type of ‘control’.  However, after some discussion, I realized I was not listening well enough, and in fact, there is an easy way a requisition user can change the quantity, amount, etc… as they turn the requisition into a PO – after it was approved!  YIKES!!!!
GP Life Hack #176 – Requisition to PO – A Workflow gap identified! (and fixed!)

Here’s the scenario.  We have requisition workflow setup providing proper approval for a requisition.  The requester also has the ability to take the approved requisition and generate the PO.  Let’s stop there and dissect that a bit.
An approved requisition is editable within Dynamics GP.  The requester, justifiably so, has access to change the quantities, amounts, etc… even after the document is approved.  This is handled perfectly by GP and warns the user that making the change will recall the requisition, therefore requiring another approval process.  Perfect.

The scenario I just described – requisition document changes – is what I was originally thinking my fellow GP user was referring to… however, it was not.
If no changes are made to the requisition, and the user chooses the action ‘Purchase’, the Purchase Orders Preview window opens… (sort of the in between step).
From here, if the user makes any changes that pass GP validation,  the intended workflow approval from the previous window gets bypassed (not really bypassed… this is why I call it a ‘gap’)!  Take a look at my example below. (yes, I like Pizza!)

Great discovery!  But WOW, left untouched, this can be a scary situation for your organization!  This business process is quite normal for GP businesses – sure, you can have PO approval and a separation of duties that has the requester restricted from generating the PO, but the fact is that many businesses have this responsibility fall on the requester.
So, how do we handle this?  Let’s #LIFEHACK this so we can safely continue to leverage the GP workflow without adding extra steps to our business process.
Never fear… field level security is here!
Field Level Security is an administrator function included with Dynamics GP.  It can be found under: Administration>>Setup>>System>>Field Level Security
Simply add FLS to the fields that you want protected – voila!  Now, in the event that the requester might need to make a change, they will then be forced to recall the document and resubmit! (ahhh, perfect!)
Field level security is something I tend to use as my ‘go to’ solution if all else fails.  In this case, I didn’t think much about it and went to Field Level Security directly… Maybe you have other ways to handle this?  I’d love to hear your thoughts!
Here is a video on what this looks like – as well as how to create the field level security!
 

I hope this was helpful!
Thanks,
Shawn