I received a request today asking if it is possible to enforce a rule in GP so that the user who creates a batch cannot approve that batch.
I initially thought that this would be an easy thing to enforce using a few lines of VBA. But then I took a look at the fields for the Batch record in the SY00500 table, and saw something odd.
When I created several different batches in Dynamics GP 2018, the USERID field was not reliably populated in the SY00500 batch table.
 |
| User ID is not consistently populated in SY00500 |
This seemed odd. Why would the USERID value be inserted for GL and SOP batches, but not IV and PM?
As far as I can tell, the issue is not a technical limitation, as the Batch Entry windows appear to all call the same stored procedure: zDP_SY00500SI. It appears that the developers were simply lazy and either didn't bother to retrieve the current user ID, or didn't bother to pass the value to the stored procedure?
 |
| User ID not supplied when the IV Batch Entry window calls zDP_SY00500SI |
Very odd.
In theory, you could write SQL triggers to fix this, but ensuring that SQL triggers are reliable and don't interfere with any other Dynamics GP processes is often more difficult that you would expect.
So this simple request to try and improve the Dynamics GP batch approval process appears to be much more involved than I would have hoped.
Update: Mariano replied to me on Twitter, noting that the User ID field is not really intended to be used to identify the user who created a batch--it's used as part of the posting process.
So it seems the User ID field is not a viable option for determining who created a batch.
Steve Endow is a Microsoft MVP in
Los Angeles. He works with Dynamics GP, Dynamics 365 Business Central, SQL
Server, .NET, Microsoft Flow, and PowerApps.
No comments:
Post a Comment
All comments must be reviewed and approved before being published. Your comment will not appear immediately.