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 with a client, who requested that the Transaction Description be printed 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, there were 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/replaced 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, with no trigger, and 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. 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 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 transactions) 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 "hidden" 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 have been surprised to hear this 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 Project Accounting is not installed.  Sounds backwards already, doesn't it?

Here's the situation:

  • If Project Accounting (PA) is 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 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 PA is installed, or it's removed from your launch file, the Reference only flows to the GL, not to the Transaction Description. Strange but true!

I tested this on GP 2013 R2, GP 2015 R2, GP 2016 R2 - all behave the same way.

Here's some proof - without PA

Sample 1: without PA enabled, these are GP 2016 R2 examples by the way…

Non-PA receivings window
An example of a Receivings Transaction entry without PA installed.
Type a description in the Reference field
The same transaction's Distribution Entry window shows a reference has been typed in.
Result: no description in the PM tables
The same transaction after posting, in Accounts Payable, and the description did not flow through.

Same example with PA installed/enabled in the .set file

PA version of Receivings Trx Entry
A second example is with Project Accounting installed.
Type in Reference field
The second example's distribution window where another reference is typed in.
Description flows to A/P
The second example after posting in A/P shows the description flowed through.

Solutions

So, there aren't a ton of options if they still insist on printing the transaction description on the remittances for reviewers and 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 screenshot of most of it, some of the comments have been removed to protect the innocent! :)

A SQL query of a trigger to update the Payables Transaction window description field.

I've also logged a suggestion with Microsoft Connect (link removed, no longer valid) 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, that what I think is obvious isn't always obvious to someone else!