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?
D365FOE 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 detailsIn 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 journalJust as we suspected — 4 journal entries, as outlined earlier. Notice that the journal entries are balanced in each of the legal entities’ ledgers (1).
It’s a simple example, but nice, right?
Fixed financial dimensions
Note: I’m assuming you’re familiar with fixed financial dimensions. If not, please review the financial dimensions and posting article from Microsoft Docs.
Let’s thrown in some real world complexities.
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 dimensionsIn 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 dimensionsWe 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 transactionsThe 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.
DebuggingIf 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.
DebuggingWhen 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 greatnessOkay, 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?
Well, there’s an API for that. We’re going to create an extension, leveraging the chain of command (CoC) functionality introduced in platform update 9.1
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.
| [ExtensionOf(tableStr(AccountingDistributionTmp))] | |
| final class AccountingDistributionTmp_Extension | |
| { | |
| public void applyFixedDimension() | |
| { | |
| next applyFixedDimension(); | |
| if(SourceDocumentLine::find(this.SourceDocumentLine).SourceRelationType == tableName2Id(tableStr(TrvExpTrans)) | |
| && this.PostingType == LedgerPostingType::VendBalance && this.LedgerDimension) | |
| { | |
| this.LedgerDimension = LedgerDimensionFacade::serviceApplyFixedDimensions(this.LedgerDimension, Ledger::findByLegalEntity(this.SourceDocLineLegalEntity).RecId); | |
| } | |
| } | |
| } |
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.
DebuggingSo 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 transactionsAnd 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.↩
Version: app 7.2, platform 10
Better with Dynamics 365 