Time for one of those obscure issue blogs, that won’t affect very many people, but the odd person might find this very useful to clarify what they are or are not seeing happen (and give me a couple of years, I’ll forget, and find my blog post!).
This story starts at a client, who requested that the Transaction Description prints on a cheque/EFT remittance. Sounds easy right? Well, the client found out at some point when first using GP that any descriptions in POP transactions they typed in were not updating PM tables, therefore no descriptions for the reviewers or vendors. So, they called their VAR for help.
Cue the VAR, who at some point early in their original implementation with Dynamics GP 2010, added an Extender window on the Invoice Match Entry window, for A/P Clerks to type in a transaction description, and a SQL trigger on the POP30300 table, to update the PM20000 table with that description after posting completes. Last year, during an upgrade to Dynamics GP 2013, I was new to this client and the issue came up during testing because (of course) the trigger wasn’t upgraded/replaces after the upgrade, no one knew it existed, and the descriptions stopped populating PM tables again.
When the client noticed the problem, I made a note to look into this in the future. First of all, they didn’t need an Extender window when there is an out of the box Reference field in all the POP transaction windows! Second of all, why should we be using a trigger on something so basic? It warranted looking into further to see why this was needed in the first place. (I understand the end goal of the description pushing down to payables but the smelled like something that should just occur out of the box, no trigger, no add-on windows…)
Side note: This is a perfect example (to me) of one of the most dangerous kinds of customizations possible. If I’m scanning a potential client’s system for customizations to prepare a quote on something, honestly, 90% of the time it wouldn’t cross my mind to look for custom triggers. VBA? Yes. Integrations with complex code? Sure. Modified Forms? Absolutely. You get the idea… I would see that they have some Extender windows but wouldn’t necessarily assume there may be SQL triggers behind any of them.
Re-visiting this issue
A few weeks ago, the client asked to take a look at the receiving process. Due to this customization, it required the Payables Clerks to enter *any* PO-related transactions in 2 steps – a Receiving and then an Invoice Match. Why? The Extender window on was only put on the Invoice Match Entry window, so they had to use that window if they wanted the description to flow to A/P. Doh! And, whatever they typed wasn’t flowing anywhere other than A/P, so the GL descriptions were still generic “Receivings Trx Entry” etc. Double Doh!
They happen to have a fairly equal split of inventory and non-inventory POs, which means about half of the “2 step” process they were doing could be done in one step as a Shipment/Invoice. The rest are received as Shipments by the warehouse guys and Payables is only Invoice Matching so that part still would be in the Invoice Match window.
It was clear to me they needed to be able to type in the description on either Receivings Transaction Entry (shipment/invoice trxs) or Invoice Match and both need to flow to the A/P module’s Transaction Description field.
Time for a “did you know?”
POP transactions (Receiving, Invoice Match, Returns) have a transaction description field called Reference in the Distributions window at the top of the screen.
Didn’t know that? More than a few people have posted this question on forums and been surprised to hear this actually exists. It’s hidden, yes, but one click away, and as a bonus, this description field also flows to the Reference field in the General Ledger.
Time for some testing
Here’s where the obscurity comes in: this is only an issue when you DON’T have Project Accounting installed. Sounds backwards already, doesn’t it?
Here’s the situation:
- If you have Project Accounting installed, whether you use the alternate window or not, as long as you are using Dynamics GP with PA in your dynamics.set file, the “Reference” in POP transactions will flow to “Transaction Description” in A/P. THAT part alone was weird. I actually turned off the alternate window, while still logged in with PA in my dynamics.set file, and the description flowed through to PM properly.
- If you don’t have PA installed, or it’s removed from your launch file, the Reference only flows to the G/L, not to Transaction Description. Strange but true!
I tested this on GP 2013 R2, GP 2015 R2, GP 2016 R2 – all behave exactly the same way.
Here’s some proof – without PA
Sample 1: without PA enabled, these are GP 2016 R2 examples by the way…
Same example with PA installed/enabled in the .set file
Solutions
So, there aren’t a ton of options if they still insist on printing the trx description on the remittances for reviewers and for the vendors themselves. It came down to removing the Extender window, which was useless since there already is a field they could use for this description, and re-writing the trigger to simplify the code for bulk insert operations. Here’s a screen shot of most of it, some of the comments have been removed to protect the innocent! 
I’ve also logged a suggestion with Microsoft Connect, because it’s unclear if this is a bug, given the different behaviour depending on products in use, or if it’s a feature request. It is a pretty basic one to me but history proves, what I think is obvious isn’t always obvious to someone else!
If you’d like to vote on it, follow the link and thanks!
(originally posted on www.kuntzconsulting.ca, and migrated to this site in October 2017)
