UPDATE: As James Crowter notes in the tweet shown below, D365 Financials has been updated to allow entry of GL accounts on transactions, similar to the full Dynamics NAV product. As a result, some of the discussion in my post below isn't relevant anymore, but the discussion of philosophy around access to GL distributions on transactions is timeless!
https://twitter.com/JamesCrowter/status/864529798642663424
In my last post on Dynamics 365 Financials training, I mentioned that in the first day, one difference I noticed was that D365 Financials does not allow access to transaction distributions during transaction entry, and that users cannot change distribution accounts directly on a transaction. Dynamics 365 Financials (NAV) uses a different design involving "Posting Groups" that control the GL account assignments for transactions.
As someone who has worked with Dynamics GP for a long time, this seemed like a big difference to me. In the GP world, Distributions are a pretty big deal. When certain transactions are entered in GP, you often have to verify the distributions. And some customers have processes that require users to change the distributions.
For example, some customers may manually code revenue accounts on a sales invoice, while other customers may code expense accounts on a vendor invoice. In the GP world, Distributions are a thing, and they're an important thing. When transactions fail to post, we sometimes ask customers to check the posting journal or Edit List to see if the distributions might have an issue. When importing transactions using eConnect, I have to make sure that the correct distributions are imported. We're so used to dealing with Distributions that it's second nature for us in the GP world.
After reading my blog post, Mariano Gomez asked a reasonable question:
I had the same reaction when the trainer explained the D365 Posting Groups and how they needed to be setup for all customers, vendors, and items so that accounts could flow through to transactions. It sounded complicated. This is the actual question I asked the trainer:
Is the setup of posting groups tedious & time consuming for customers? It seems like a lot more work to setup in advance than what a GP customer would be used to.
She explained that for most customers, the setup is not too difficult or complex. As long as the customer doesn't have a ton of revenue or expense accounts, and as long as they don't have many different AR and AP accounts, the setup of Posting Groups not difficult. She really knows her stuff, so I trust her.
So perhaps addressing the underlying point of both Mariano's question and my question: What is the benefit of the Posting Groups, which appear more complex?
After just one day of training on D365 Financials, I'm far from an expert, but my interpretation is that the Posting Groups allow you to configure the system to default the posting accounts, similar to GP, but for every situation and scenario. The design of the Posting Groups apparently allows the system to handle different scenarios that could not otherwise be handled by a single default account.
For some companies, GP account defaults may easily handle all scenarios, but for other companies with more complex business models, GP default accounts don't cover every situation with a vendor or customer, and a user must manually enter or change a transaction distribution.
So why are Posting Groups beneficial rather than a complex hassle? My interpretation is that it is beneficial for a system to automate the GL account assignment for transactions 100% of the time. If the system can fully automate the process, why would you ever want a user to have to do it? If that takes a few more hours during implementation, I'd say it's worth it if you can eliminate the Distribution window. Stop wasting a single second selecting GL accounts at the transaction level while avoiding incorrect posting accounts on transactions.
Let go of distributions completely. Think of Distributions as a burden rather than a benefit.
That's my positive spin on what I saw today. If you eliminate the Distribution window that we're used to in GP, the ERP system needs to have a comprehensive process of defaulting GL accounts on transactions. Dynamics 365 Financials adopted NAV, which uses the concept of Posting Groups to address that need.
If it seems complex or burdensome or like it will be a hassle or restrictive, I then consider the estimated number of NAV customers. My thought is that if it works okay for over 110,000 companies with a far broader geographic distribution than Dynamics GP, it must be a viable solution. With training and some experience implementing D365 and configuring Posting Groups, I expect it to be no more complex than setting up all of the default GL accounts that are scattered throughout GP.
Is it different than GP? Absolutely. Is that a bad thing? Not necessarily. I think that the little bit of extra setup time up front can provide significant benefits long term. And I would personally be perfectly happy if I never had to directly interact with Distribution records ever again.
Before I get beat up for this Dynamics GP heresy, nay, this GP blasphemy!, I will preemptively offer the counterpoint: Are there some downsides to not having a Distribution window?
ABSOLUTELY. Not having access to transaction distributions can be a royal pain in the butt for some unique businesses and some unusual business processes.
I know this because it was a nightmare for me to develop a customization for a NetSuite customer that needed to automatically change GL accounts at the transaction level. That cannot be done in NetSuite, because there are no distributions. And that is frustrating and limiting and annoying. So I've been in the trenches in that scenario as well.
Once I learn a lot more about D365 Posting Groups and GL account assignments on transactions, I will be happy to wage war on the anti-Distribution argument in support of the Dynamics GP Distribution window. Until then, I'm giving D365 the benefit of the doubt.
Steve Endow is a Microsoft MVP
for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.
He is the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
I don't think there's an easy conclusion. On the sales & inventory side of things, it should be possible to configure the theoretical combinations of posting accounts that are relevant, as there would be a pattern that doesn't require judgement of the end user to get correct.
ReplyDeleteOn the payables side, where inventory purchases are not involved, I would want to see more details about how this works. Vendor invoices - from the same vendor - can often be coded to a multitude of different expense accounts across various departments or cost centres. From what you've described I can't yet reconcile in my head how this would work for those types of situations. Not having seen the functionality, it's just me not understanding how robust or not the functionality is.
Otherwise, this posting group stuff must only apply to the subledgers correct? Clearly you can't pre-define every type of financial journal entry you might need to record; many yes, but not all. I'm assuming there is a core journal entry functionality that allows authorized users to post directly to X and Y GL accounts if and when needed?
Keep up the posting and tweeting from your training... it's kind of like getting 1/4 trained with you. :)
Jen
Hi Jen,
ReplyDeleteYes, I have similar questions on the AP side as well.
The Purchasing Invoice transactions have line items that must be tied to Items that are already setup in the system. You cannot enter a free form item number. So if you want all AP transactions to be entered through that window, I suspect you'll need to have quite a few items setup to handle everything rent to carpet cleaning to the pizza for office parties.
However, there is an alternative entry method called Purchase Journals that appear to be like an unusual subledger journal entry. You enter amounts in a grid that can post against a vendor while also posting to the GL. This approach appears to allow more flexibility, but it seems like a weird entry mechanism to me. It isn't the same as a formal AP transaction.
Apparently NAV does have a process for entering the equivalent of a Dynamics GP PM Voucher, but currently D365 Financials does not have that same process.
Steve