Author: Joshua Cabrera

What do you do when looking up your vendor payment details doesn’t work as expected?

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.

Opening a vendor’s payment history

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.

Vendor payment history

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.

Vendor payment history

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.

Debugging

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.”

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

And that’s why we can be seen around the office like this on some days:

My face when there’s a hotfix

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.

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.

Vendor payment history

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!

What do you do when your fixed financial dimensions are not working as expected?

In this post, we cover a complete walk–through, including resolution, of an issue where posting intercompany expense reports results in general ledger vouchers with inaccurate financial dimensions.

Let’s start with the business and functional background.

Intercompany expense reports

As businesses grow, they quite commonly evolve from a single legal entity into a complex organization of multiple legal entities. In my own experience, I can count the number of projects involving a single legal entity on one finger! Yes — that’s a poor attempt at humor, not a typo.

Despite the proliferation of intercompany accounting, for businesses using multiple legal entities, intercompany accounting is a common pain point unfortunately.

Intercompany accounting relating to expense reports arises when an employee and expense report are associated with legal entity A yet the expense is allocated to legal entity B. Here are some journal entries for fun:

A’s ledger
Cr — Accounts payable

B’s ledger
Dr — Expense

The debits and credits are balanced. We’re all good, right?

No! It just so happens that accountants are very particular creatures. While the debits and credits are balanced, they are not balanced within each legal entity. We need additional journal entries to appease the accounting gods. Here are more journal entries for more fun:

A’s ledger
Dr — Intercompany due from B
Cr — Accounts payable

B’s ledger
Dr — Expense
Cr — Intercompany due to A

So, what if it wasn’t painful? What if it just worked? What if we used D365FOE?

D365OE enables this business process by allowing an expense to be coded/attributed to another legal entity at the time of entry, or before submission, and the accounting framework posts the intercompany accounting entries automagically.

Let’s see what this actually looks like in the application.

Expense details

In legal entity USMF (1), we have an expense report for Julia Funderburk with 1 expense, which is coded to a different legal entity — USSI (2). Let’s click on subledger journal (3).

Expense subledger journal

Just as we suspected — 4 journal entries, as outlined earlier. Notice that the journal entries are balanced in each of the legal entities’ ledgers (1).

Fixed financial dimensions

Go back to the last screenshot. Do you notice anything unusual about the ledger account entries in the subledger journal?

That’s right — only the main accounts are set. All financial dimensions, or segments, are blank.

Now, for those of you still here — we all know that’s blasphemy. Please forgive me.

Let’s say that due to given how financial dimensions are used in our environment and certain statutory reporting requirements, we need the accounts payable main account to have fixed financial dimension 1 in legal entity A and fixed financial dimension 2 in legal entity B.

Let’s review the configurations for the main account in the application.

Default financial dimensions

In the main account details, we filter for the accounts payable main account (1), and in the legal entity overrides, we add records for USMF and USSI.

Next, we select USMF (2) and click on default dimensions (3) to open the dialog where we set the “BusinessUnit” financial dimension to fixed (4) and the fixed financial dimension value to “001” (5). Let’s do USSI now.

Default financial dimensions

We select USSI (1) and click on default dimensions to open the dialog where we set the “BusinessUnit” financial dimension to fixed (2) and the fixed financial dimension value to “002” (3).

So, with our updates, we expect that the accounts payable entry in USMF will change from “200110––” to “200110–001–”, using the legal entity override for USMF.

Not. So. Fast.

The section where we finally cover the actual issue

So what happens? Let’s take a look at the voucher transactions.

Voucher transactions

The accounts payable entry in USMF shows “200110–002–” (1).

What the heck? It’s using the fixed financial dimension value for USSI?

Yes.

But how?

If we debug the posting process, we find that the fixed financial dimensions are applied by a method named applyFixedDimensions in the AccountingDistributionTmp table.

Debugging

If we look at the value for LedgerDimension (3), we can see the value before the fixed dimensions are applied because that code (1) has not yet executed due to the breakpoint.

Now look at the value for Ledger (2), and then look back to the code (1). Do you see how the method uses the ledger to apply the fixed financial dimensions?

Because the accounting distribution is in USSI, the ledger is also calculated as USSI.

Debugging

When the code executes, it applies the fixed financials dimensions for main account 200110 using legal entity USSI, resulting in the “200110–002–” value (1).

So where do we go from here? Of course, please work with Microsoft support, partners, team members, yada, yada, yada. But besides that?

Fix it!

Well it’s not rocket science, Seth. It’s a simple 3 step process.

Step 1 — FIX!
Step 2 — IT!
Step 3 — FIX IT!

Then repeat steps 1 through 3 until it’s all fixed!

Click and skip to 5:00 for 2 minutes of Saturday Night Live greatness

Okay, now that I got that out of the way…

Whether you’re a consultant or an end user, you have a client who wants the issue fixed by the time they’re having their morning bowl of Cheerios.

So how do we fix it 1) swiftly to enable end users and 2) without overlayering the application?

The CoC allows our extension to execute immediately after the standard code for applyFixedDimensions methods executes, enabling us to update how the fixed financial dimensions are applied, but before the application execution continues onto other methods.2

Let’s jump right into it.

In lines 8–9, we have an if condition so the actual update only occurs if 1) the transaction is an expense report line and 2) for the accounts payable entry.3

In line 11, we use the same method as the standard applyFixedDimensions method to apply the fixed dimensions except, instead of using the ledger from the accounting distribution, we lookup the ledger for the source document’s legal entity, which is USMF since the expense report is in USMF.

Debugging

So after our extension executes, what does the accounts payable entry look like? Take a look at the value for LedgerDimension (1). Oh, you don’t believe me?

Well, since seeing is believing, let’s post an expense report with the extension in place and look at the voucher transactions.

Voucher transactions

And there we have it — the accounts payable entry is “200110–001–” (1), using the value for USMF.

Our fixed financial dimensions 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!

1. Check out MFP’s blog post for a closer look at CoC.↩2. That is the magic of “next” in line 6 in the code snippet.↩3. Astute readers should note that the issue also affects the intercompany accounting entry in USMF, but that’s out of scope for this post.↩