For background, please see my introduction to this series, NetSuite vs. Dynamics GP: A Series
My first NetSuite project was a customization. To simplify the requirements, let's just say that the customer wanted to categorize all sales into 3 different sales GL accounts based on certain criteria. This required that each line item on an invoice be evaluated to determine if that line should use Sales Account 1, Sales Account 2, or Sales Account 3. The activity assigned to the sales accounts then will flow through to the GL and show up nice and neat on financial reports.
Since I didn't yet know how this could be done in NetSuite, my first thought was, "How could this customization be done in Dynamics GP?" In general, my preference is to get data correct as early as possible in the business process. So if it is possible to ensure correct data as it is entered for the first time, that is ideal. Sometimes that isn't possible, so you then have to run a routine later in the process.
In Dynamics GP, you could use VBA or VS Tools or Dexterity to analyze the line items on an invoice and determine the sales accounts to be used, and then modify the sales accounts used by the invoice when the transaction is saved. Or you could use those same three development tools to perform the analysis on invoices after they have been saved to a batch. You could work with the sales accounts via the user interface, or you could work with them via SQL. There are several opportunities and approaches to solve the problem, and the solution would affect the data during or immediately after data entry, before the transaction is posted.
Dynamics GP has transaction "distributions" that are child records for a transaction. So for this customization, we could adjust the distributions, add lines, and remove lines to direct amounts to the appropriate sales accounts.
This screen shot shows an invoice with three different Sales distributions that I entered manually. The $216.09 can be spread across as many sales accounts as desired. This can be accomplished with one of the development tools and / or SQL. These changes are saved with the invoice, and when the invoice is posted, these distributions are posted to the General Ledger. For Dynamics GP consultants, this is probably fairly obvious and makes sense.
UPDATE: While speaking with a client today, it occurred to me that the Sales account can be specified at the line item level in GP. If you open the Sales Item Detail Entry window from an invoice line, there is a Distributions button on that line entry window. That displays the default distributions for that line item.
This feature would have been very convenient for this particular project, as it allows you to change the Sales account at the line level without having to touch the document level distributions. This would make the customization much easier to accomplish.
So now lets jump over to NetSuite.
Aside: I am new to NetSuite, so anything I say about NetSuite is not authoritative--it's my assessment based on the research I've done and some of the advice and guidance I have been given. If I mis-characterize NetSuite functionality or describe anything incorrectly, please let me know.
In NetSuite, when you enter a new invoice, there are no distributions. You enter the invoice header information, and then enter your line items. There is no window or tab to enter or view GL accounts like the Dynamics GP Distribution window, and as far as I know, there is no option to view or change the GL accounts during invoice entry.
Once you save the Invoice, you have the opportunity to view the "GL Impact" of the Invoice transaction.
The GL Impact window lets you see the GL accounts and amounts for the transaction, but the information cannot be modified.
At this point, the Invoice has been saved and committed in NetSuite, so how can we create a customization that will split the invoice amounts across up to three different sales accounts?
Our first test was to see if it was possible to use the SuiteScript language (a scripting tool similar to Dynamics GP VBA) to modify the transaction right before it is saved. Our hope was that we could insert the sales GL accounts we needed into the transaction and have them retained when the Invoice is saved. While we were able to modify the sales GL account of the invoice before it was saved, as soon as NetSuite received the transaction, it would overwrite any of our values and apply default accounts. As far as we could tell, this approach would not work.
Our next plan was to "reclass" the sales activity for an invoice. So if we had an invoice that posted to account "4000 Sales", we would write a script to review the customer and line items and then create a journal entry to debit 4000 Sales and credit Sales Account 1, Sales Account 2, and Sales Account 3.
While simple in concept, this approach has one important drawback--it means that instead of one transaction to categorize the sales in the GL, we now have two: the original invoice, and a corresponding reclass JE.
Why is this a drawback? First, it means that instead of one transaction, you now have two. When reconciling the GL or financials, you will trace sales to journal entries rather than invoices. Once you find the JE, you would then need to lookup the originating invoice.
Second, in NetSuite, unlike Dynamics GP, transactions are only saved, they are not posted. And in NetSuite, saved transactions can be modified and deleted. Consider that an invoice might be modified. Maybe a line is added or removed or an amount is changed. That means that the corresponding reclass JE needs to be changed. It's maintenance, and it can get complex if multiple changes are made to an invoice.
We were able to develop a SuiteScript solution that created the reclass JEs for invoices and then managed changes to the JEs if an invoice is modified or deleted. And it also had to manage the effects of a credit memo for the invoice--so if an invoice line is later credited, the JE had to consider that change and create a new reclass JE. It also reversed the sales reclass JE if the invoice was deleted. And there were several other details that made the solution even more complex, but we eventually pulled it all together and produced a relatively clean solution.
So this project highlighted one specific difference between Dynamics GP and NetSuite. Dynamics GP has editable transaction distributions that can be viewed, and also edited before a transaction is posted. NetSuite appears to keep the GL accounts behind the scenes, so there is no opportunity, and apparently no need, to view or edit the GL accounts for a transaction before or after it is saved.
In this particular case, the design of Dynamics GP would have made this customization easier to develop, but I would say that is coincidence, and not a justification of the GP design.
Having worked with Dynamics GP for many years, I have accepted that transactions have GL distributions that can be modified--perhaps even when they shouldn't be. Distributions have caused more than a few issues when a user makes a mistake.
The NetSuite approach of not having editable GL accounts during transaction entry would appear to be simpler. But I wonder if there aren't many businesses that might need to or want to modify the distributions--obviously at least one customer wanted invoice distributions modified.
Is there a compelling case to expose GL accounts / distributions for transactions, perhaps to accommodate more flexible account coding or customizations? Or should a system be setup to default all of the accounts, minimize mistakes, and maintain tighter control over the GL impact of transactions?
One could just as easily argue that this customization should have been accomplished in a different manner entirely and that Distributions and GL Impact shouldn't have mattered--but that was an option we didn't have in this case. In reference to my opening point about getting the data right as early as possible, perhaps it would have been possible for the customer to change their business process and data entry process so that a different invoice type was used for the different sales, or use different inventory items that would correspond to the different sales accounts. There are pros and cons to those approaches, but the obvious downside is that it would require the business to modify its processes to accommodate a relatively small financial reporting requirement. Sometimes referred to as the tail wagging the dog.
As an ERP consultant should know, accounting and financial reporting requirements generally do not dictate changes to sales and operations. Sales and operations do what they need to do to keep the business running, and it's up to the accounting department and ERP consultants to figure out a way to get the transactions, GL and financial reporting in good shape.
Written By Steve Endow
Steve Endow is a Dynamics GP
Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.
He is also the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
