In this post, we review an issue when using the vendor payment history form, which opens an incorrect invoice when inquiring into payment details.
Let’s start with the business and functional background.
Vendor payment history
An accounts payable team member usually responds to external and internal inquiries regarding vendor payments and the corresponding vendor invoices several times per week or day.
The vendor payment history form enables the user to respond quickly. Let’s take a look.
Easily accessible from the vendor account, the payment history (1) displays payments in the past 12 months by default, which can be switched to show all, and also enables searching by invoice or purchase order.
When we select a payment in the top grid (1), the form displays the related data in the bottom grid (2). Another nice feature of the form is that the data in the bottom grid is automatically refreshed as the user selects different payments.
Now imagine you want to drill down into an invoice for more details — e.g., the invoice date, so you click on invoice 309 (vendor account 1001) to open the invoice journal form.
What’s this?
Invoice 123456 (1) for vendor account US–108 (2)?
But we clicked on invoice 309 for vendor account 1001?
The issue
This issue is a bit of head–scratcher at first.
As usual, we discussed it with the user who reported the matter, and as far as they remember, it was the first time they experienced a problem performing this action. And after reviewing the details of the data from the front end, there’s nothing that stands out.
So what now?
We take out our favorite technical team member to coffee and ask for help.
After reviewing the code, the ruling on the field stands — it’s a bug.
Looking at the X++ for the form (1), we see that the code is looking up the invoice by using the invoice record’s source document header (2).
So why is that an issue?
Not every invoice uses the source document framework.
What’s that?
“A Source Document is an original record that documents the occurrence of one or more Business Events in an accounting system. Concrete Source Documents, such as purchase orders, product receipts, and vendor invoices, are entered into an accounting system that records, classifies, tracks, and reports on the quantity and value of economic resources that are exchanged or committed for exchange when activities identified by Business Events such as purchase, product receipt, and payment request are performed.”
— Inside Microsoft Dynamics AX 2012 R3 (Seriously, get it.)
That’s a mouthful, but also key to understanding what “source document” means in our little world. I’m feeling lucky and rolling the Google (or Bing!) dice one more time…
“A source document is the original record containing the details to substantiate a transaction entered in an accounting system.”
Ah, that’s more digestible. And it beats my definition:
“A source document documents the source of a transaction.”
Anyway, a key takeaway is that not every voucher, or accounting transaction, uses the source document framework. Many transactions, such as general journals, create vouchers in a different manner than the source document framework.
The (hot)fix is in
With great power, comes great responsibility…to check issue search on Lifecycle Services before pulling the proverbial fire alarm. And so we search.
And that’s why we can be seen around the office like this on some days:
Note: When this issue was added to my backlog, there was no hotfix available. I only found the hotfix while drafting this post, which serves as a nice reinforcement to always use issue search. The post survived getting axed by the hotfix because sharing the root cause is nevertheless valuable in this case.
Anyhow, we install the metadata hotfix and then revisit the form’s X++.
We can see that the update uses the RecId from VendInvoiceJour to retrieve the invoice record (1), making this method more robust since purchase order invoices, vendor invoices, and vendor invoice journals all normally create VendInvoiceJour records.
Let’s try drilling down into the invoice again.
Ta–da — the form opens invoice 309 for vendor account 1001 (1).
Our vendor payment details are working as expected.
How are you making your people, process, and product better with Dynamics?
And if you’ve enjoyed this post, please bookmark the website and/or share this post using the buttons below!
Version: app 7.2, platform 10
Better with Dynamics 365 