D365 F&O Errors: What Does the "Allow Multiple Transactions Within One Voucher" Parameter Really Mean?

I wanted to share a discovery from a recent issue I had with failures to post fixed asset transactions that trigger automatic depreciation adjustments. It can apply to several other transaction types in other modules, as well.

Since the 2018 Spring Release, you may have noticed a new error message when setting up a D365 environment and attempting to post things like fixed asset disposals or basis adjustments, bank-to-bank transfers, customer reimbursements, etc. It says something along the lines of "There can only be one ___ transaction per voucher" (where ___ is the transaction type you are posting).

This is because Microsoft has introduced a new General Ledger parameter labeled "Allow multiple transactions within one voucher." It comes with all sorts of scary warnings in both the help text pop-up and when you turn it on.

The context of the warning messages and the descriptions in the article referenced in them could lead you to believe that turning this on will cause the user's entire world to crash down upon them. But what does it really mean? And what risk are you introducing by turning it on?

Simply put, turning it on adds no more risk to the user's environment than it did in previous versions. What Microsoft realized is that having multiple customer or vendor accounts on a single voucher can mess up how those transactions get reported in the subledgers and how they get settled for payment, cash discounts, or foreign exchange (see Microsoft's examples here.)

Therefore, by default, they no longer allow anything but multiple Ledger transaction types to be on a single voucher. However, they added this parameter to bypass the new restriction because there are still some functional gaps that will cause some normal types of transactions to fail with this restriction in place, including automatic fixed asset depreciation adjustments, bank-to-bank transfers, customer reimbursements and more (you can see the full list here).

Microsoft intends to work on closing these functional gaps in future releases, and once that is done they will remove the parameter. Until they do, you may find it beneficial to turn this parameter on for several reasons.

First, turning it on does not introduce anything new to the system. On the contrary, leaving it off introduces a new universal posting restriction that can cause some features to stop functioning.

Second, if you're a knowledgeable Microsoft partner, you already know the impacts of having multiple vendors, customers, or even bank accounts on a single voucher, which is why they have best practices such as:

• Only turn on "One voucher number only" on a Daily journal type when it is restricted to only Ledger transaction types via Journal control.
• Only use journals for vendor and customer transactions where necessary (Vendor payments, Customer payments, and sometimes a Vendor invoice journal) and always set the vouchering for those journal names to "In connection with balance."
• Enter transactions through methods that already prevent having a single voucher with multiple vendors, customers, or bank accounts, such as using payment proposals, entering manual customer payments via the Enter customer payments screen, and using the Pending vendor invoice screen to enter most invoices.
• Where vendor, customer, or bank account transactions are manually entered into a journal, warn the client not to try to put multiples of these account types on a single voucher (with the exception of 1:1 transfers).

As you can see, if you are simply following the standard process of entering the lines one at a time, it can actually be difficult to cause issues. And in the rare cases when a user does accidentally cause an issue, they typically can't post anyway because their vouchers will be out of balance.