Wednesday, July 31, 2013

NetSuite vs. Dynamics GP: Save Transactions vs. Post Batches

For background, please see my introduction to this series, NetSuite vs. Dynamics GP: A Series

One distinct difference between NetSuite and Dynamics GP is that NetSuite allows you to simply save transactions to commit them, while Dynamics GP allows you to save uncommitted transactions to a batch, and then post the batch to commit them.

In GP, if you are entering 5 transactions, you can assign them to a batch, which allows you to save them.  The transactions are uncommitted at this point, and can be edited or deleted, depending on your configuration.  The batch is a temporary bucket that allows you to group the transactions and verify the number of transactions entered, as well as the total dollar amount of the transactions.


The batches can require that users enter control totals, indicating that they have independently verified the number of transactions and the total batch amount.  Dynamics GP can also be configured to require batch approvals based on transaction type, which is also handled by the batch window.

While I can understand the benefits of the batch control totals, it has been ages since I've seen anyone actually use that feature--as in use a 10 key to independently total their transactions.  I'm sure there are a few companies that use the feature, but in my experience, it has been very rare in the last 10 years.  I don't know if this is a shift in attitudes towards data entry controls, or if it is due to a higher comfort level with accounting system reliability, or some other reasons.  But it seems as if the batch control totals may be an anachronism and are not as important to businesses as they once were.

The batch approval seems a little more practical.  If an AP clerk enters 10 invoices, a supervisor can have the opportunity to quickly review the transactions, verify them, and then approve the batch prior to posting.

So that is a quick overview of GP batches.  NetSuite has a very different approach:  no batches at all.

When you enter a transaction in NetSuite, you have the option to Save the transaction.


Once you save the transaction it is committed.  No batch, no separate posting step, no control totals.

Is the lack of batches a benefit?  Is the lack of a posting process a good thing--just one less step to deal with?  NetSuite users would probably furrow their brow if you asked them about batches--why would they want or need them?

Since there are no batches in NetSuite, approvals are at the transaction level.  I'm not yet familiar with the approval functionality, but it appears that you can setup a workflow to obtain approval, which is a nice touch.

What is perhaps more significant about NetSuite is that after a transaction is saved, it can be opened, edited, changed, and even deleted.  This is very different than the more 'conservative' approach in Dynamics GP, where a posted transaction cannot be modified or deleted.  Dynamics GP allows some transactions to be voided, and allows GL journal entries to be reversed, but each of those operations is explicitly tracked, and you have a strong audit trail for those changes.

In NetSuite, if someone opens an invoice, modifies it, and then saves it, or perhaps deletes an invoice, I don't yet know what controls or audit mechanisms exist to track or control such situations.  Given the flexibility and customizability of NetSuite, I'm assuming there are several options for adding controls if desired.  And I'm told that one specific control available in NetSuite is to enable fiscal periods, which can prevent transactions from being modified if they are in a prior or closed period.

This unposted-transaction design appears to be very similar to QuickBooks, which is obviously widely used by many companies, so it certainly isn't unprecedented.  But admittedly, I'm so used to the stricter controls in Dynamics GP that it's difficult for me to imagine users having the ability to edit, modify, and delete transactions.

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.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

GL Balance Migration - Net Change -vs- Debit/Credit

Yesterday I was discussing prior month GL balances with a client who went live in May. They were looking back at a specific account's activity for January, February, and March, and they were confused by what they saw. For the sake of argument, let's say that they saw a $100 credit for January, a $50 debit for February, and a $200 credit for March. So they were concerned as to why each month would only have credit or debit activity and not both. Of course, it was the end of a long day and I wasn't very quick on the uptake :) Normally, when I migrate GL period activity for the purposes of GL history migration, I try to bring in both debit and credit activity for the period. This way, all three columns of the trial balance match the prior system- Debits, Credits, and Net Change for the period. But in this case, someone else had done the migration and the fact that the prior system didn't easily produce period activity in a downloadable format, only the net change for each period was loaded. Looking at it from a client's point of view, someone who is new to the system, it reinforced for me that migrating both debits and credits may make things clearer when looking back months or years from now. And generally, this takes no additional time in the migration assuming the data is available. What do you all think? Curious to know how you all handle it?
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.


Friday, July 26, 2013

Dynamics GP Run-time Error 1007: Unsafe Operation

Several years ago I developed a customization to display the order weight on the SOP Transaction Entry window.

Earlier this week, the client said that they have been getting an error with the customization in a very specific circumstance.

If they create a Quote with a serialized item, and then transfer that Quote to an Order, they will get the following error:


Run-time error 1007:  Unsafe Operation.  An attempt was made to set a value which violates the application's business logic.

If they use a non-serialized item on the quote, the error does not occur.  And they don't get the error in any other process--only when transferring the Quote with a serialized item to an Order.

This is odd for many reasons, but rather than try and figure out why it occurs, we are lucky enough to have KB article 856199 that describes the problem and offers a solution.

In my original code, I was assigning the order weight value to the custom field on the SOP Transaction Entry form:

TotalOrderWeight.Value = FormatNumber(rst.Fields("ORDERWEIGHT").Value, 2, vbTrue, vbFalse)

Well, it seems that this can trigger the error for some reason.  The workaround is to use the Focus method to assign the value, something I had never used before.

TotalOrderWeight.Focus (FormatNumber(rst.Fields("ORDERWEIGHT").Value, 2, vbTrue, vbFalse))

Sure enough, when I used the Focus method, the error went away.  Go figure.

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.

You can also find him on Google+ and Twitter



Windows 7 Remote Desktop Connection error: Remote computer requires Network Level Authentication

By Steve Endow

In the last week, I suddenly had problems connecting to one of my Server 2008 R2 HyperV virtual machines.  I have been using the virtual machine for many months and have not made any changes, but when I attempted to connect using Remote Desktop Connection, I received this error:


"The remote computer requires Network Level Authentication, which your computer does not support."

I knew that the error message related to the Remote Desktop settings on the Server 2008 R2 machine, specifically the "Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)".  I have my virtual machines set to use the NLA option, but that hasn't been a problem in the past--I've been connecting to the servers fine from my desktop and laptop.

After further testing, I realized that I only had the problem when I attempted to connect using my laptop.  My desktop still connected fine.  Both systems run Windows 7, so both should be able to connect with NLA.

After poking around on my laptop, I found this clue in the About menu of the Remote Desktop Connection app on my laptop.


Note the message "Network Level Authentication not supported".  On my desktop, it says NLA is supported.  So it seems that something changed or broke on my laptop, disabling NLA.

After a few more rounds of searching, I finally came across this TechNet forum thread where user "Millerus" graciously posted the solution that happened to work for me.

The resolution is based on instructions for enabling NLA on Windows XP, which were listed here:

http://www.powercram.com/2009/07/enabling-network-level-authentication.html#

I had previously ignored all Windows XP related information, since I didn't think it would be relevant to Windows 7.  But it appears that something removed or modified a registry entry, disabling NLA on my laptop.

In my case, when I checked the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\SecurityProviders key in my registry, it was missing the credssp.dll file in the list.  Once I added that DLL to the security providers list, my Remote Desktop Connection app suddenly showed that NLA was supported.  I did not have to reboot my laptop--I just had to close and restart the Remote Desktop Connection app.


Finally.  Another hour wasted on some trivial issue.  Now back to work...

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.

You can also find him on Google+ and Twitter






AP Payment Application Import for Dynamics GP

One limitation of both Integration Manager and eConnect is that those import tools do not allow you to import an AP Payment Application into Dynamics GP.  You can import an AP Manual Payment, but you cannot apply that AP payment to an open AP invoice.

A few years ago a client needed to import a large batch of AP manual payments and apply them to open AP invoices, so I developed a custom import that would apply the AP payments.  Since then, I've been in touch with several more GP users that need to import AP payment applications, so I now offer the import as a product.

The AP Payment and Apply Import can import AP Manual Payments and AP Payment Applications.  The application imports payments from one data file, and applications from a second data file.  Payments and applications can be imported together at the same time, or separately.

Here is a brief demo video of the import application:




The only caveat is that the AP Manual Payments must be unposted for the application to apply them to an open AP Invoice--the application cannot currently apply a posted payment to an open invoice.

If you have additional questions about the AP Payment and Apply Import or are interested in a trial, please feel free to contact me at:

http://precipioservices.com/contact-us/



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.

You can also find him on Google+ and Twitter




Monday, July 22, 2013

Microsoft Dynamics GP 2013 Cookbook is available

Ian Grieve and Mark Polino have put together a great new Dynamics GP book.  This time it's an update to the Cookbook:  The Microsoft Dynamics GP 2013 Cookbook.


The book description says it well:

       Over 110 immediately usable and effective recipes to solve real-world Dynamics GP problems

The book includes 12 chapters of specific, detailed tips to help you use more features in Dynamics GP 2013 and help you get the most out of Dynamics GP.

In addition to covering several of the new features that were added to Dynamics GP 2013, the book covers a lot of less obvious or often overlooked features can be very handy.

Have you ever used Control Account Management to do divisional reporting of Accounts Payable?

Are you using SmartLists to automatically generate Reminders when you log in to GP?

Are you using the Dynamics GP Excel Reports to quickly view GP data in Excel?

Are you using the Reconcile to GL feature?

Do you want GP to warn you if you try and log in with your Caps Lock enabled?

These and many more are covered in detail in the GP 2013 Cookbook.

The Cookbook format is great because it gets right to the point with a very brief explanation of the feature, step by step instructions on how to use the feature, and then a brief note on how the feature works.  Often there is also a "There's more..." note, pointing to additional information, or other ways that the tip can be used.

Overall, the book is a great resource, and I recommend picking up a copy of the book, or purchasing the PDF or electronic version.


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.

You can also find him on Google+ and Twitter



Tuesday, July 16, 2013

NetSuite vs. Dynamics GP: GL Impact vs. Distributions

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.

You can also find him on Google+ and Twitter



Friday, July 12, 2013

NetSuite vs. Dynamics GP: A Series

By Steve Endow

The last two weeks I have been working on my first NetSuite project.  A friend of mine owns Prolecto Resources, a leading Southern California NetSuite practice.  A few weeks ago, he offered me an opportunity to work on a small NetSuite customization project, and I jumped at the opportunity.

I've read several sales and marketing articles, blog posts, "competitive analyses", and white papers about NetSuite vs. Dynamics GP, but those all seemed to have an "angle".  It isn't terribly difficult to pick the best capabilities of your product and the limitations of a competing product and declare your product the victor.  And I don't trust such comparisons, as they rarely tell the whole story--a story that is often much too big to distill into simple bullet points.

Since I've spent the last 9 years working with Dynamics GP, I'm pretty familiar with the software, its architecture, how it works, what it does well, and what it doesn't do well.  I definitely don't know everything, and I haven't worked with every module, feature, or add-on related to GP, but I'm comfortable assessing GP and NetSuite relative to my direct experience working with both systems.

There are plenty of discussions and rants about on-premise vs. SaaS, licensed vs. subscription, 'best of breed' vs. all-in-one--what might be referred to as the ERP "religious debates", so I'm not going to focus on those general issues.

In this series, I'm interested in discussing and comparing specific features, designs, or approaches in the two systems.  My goal isn't to identify a winner or say that one system is better than another.  I will likely point out pros and cons, but I expect there to be pros and cons for both systems.

My fundamental goal is to learn.  While being very knowledgeable with Dynamics GP is valuable, I am interested in seeing how NetSuite works and identify some specific similarities and differences between the two systems.  When we work with the same system for many years, I think we start to take certain things for granted.  By working with and learning about NetSuite, I'm also hoping to learn more about Dynamics GP.

The small NetSuite project that I worked on recently was a customization that involved using SuiteScript to automatically modify transactions as they are saved.  If I were working in GP, I could have easily come up with a design and coded a customization to meet such requirements--but instead I had to learn NetSuite and learn the SuiteScript customization language to figure out how to accomplish the project.  And I only had a week and a half to do it.

I have several topics lined up for this series, from how transactions are saved in NetSuite to how the SuiteScript language is used to develop customizations, and I plan on comparing each element to its equivalent in Dynamics GP along the way.  Perhaps over time I may discuss other topics such as licensing, pricing, etc.

While I have made certain observations and will be writing posts about those, I am also interested in getting some suggestions from the GP community about what you might be interested in learning about NetSuite vs. Dynamics GP.  At the moment, I'm primarily looking for very specific topics related to core GP functionality, like how are GL account numbers structured in GP vs. NetSuite.  Or perhaps there is a challenging accounting transaction or process that is cumbersome in GP, and you are interested in learning how NetSuite handles such a process.  If you have any suggestions, please post a comment below.


Update:  The first feature comparison has been published:  NetSuite vs. Dynamics GP: GL Impact vs. Distributions

Update:  The second feature comparison is now up:  NetSuite vs. Dynamics GP: Save Transactions vs. Post Batches

Update:  The third feature comparison is now available:  NetSuite vs. Dynamics GP: Navigation: Browser Tabs vs. Application Windows



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.

You can also find him on Google+ and Twitter




Batch Load Test Import for Dynamics GP

Post Master for Dynamics GP is a utility that automatically posts Dynamics GP batches.  It works very well and is very reliable, but like all software, it occasionally has an issue in some customer environments.

To try and troubleshoot some issues, we wanted to perform load testing to try and reproduce a particular issue by posting hundreds or thousands of batches in Dynamics GP.

To facilitate such testing, I developed the Batch Load Test application for Dynamics GP.  It can import thousands of test batches and transactions in minutes.


Once the batches were imported, we used Post Master Enterprise to post tens of thousands of batches to test the software and try and reproduce an issue.

The utility can also be used to perform environment load testing, such as comparing the  performance of a physical environment and virtual environment by posting thousands of batches.

Version 1.1 supports Journal Entries, AP Invoices, Inventory Transactions, and POP Receipts against a Purchase Order.

Update:  Version 1.2 includes support for SOP Invoices.


You can contact me via my web site if you are interested:

http://precipioservices.com/contact-us/



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.

You can also find him on Google+ and Twitter



Tuesday, July 2, 2013

Management Reporter- Subtracting Segments in Trees Yields Incorrect Results

We have had several clients recently update to  UR 5 of Management Reporter 2012.  For those of you that have applied updates to MR, you know that this is generally a uneventful process.  However, in some recent cases, after applying the update clients noticed that some of their reports were pulling incorrect balances.  I should note that we have seen this happen using both the data mart and legacy providers.

As we began to dig in to the reports, we noticed that the incorrect balances were related to specific reporting units in the tree.  And these reporting units were a little different, as they were excluding one particular value for dimension.  So, for example, the reporting unit had two values specified for the department dimension:
  • Add (+) a range of 00:99
  • Subtract (-) single value of 50
The purpose of this reporting unit was to pull all departments with the exception of 50.  And this functioned fine on earlier releases of MR.  So we redesigned the reporting unit, in this case, to include two ranges that effectively achieve the same end result:
  • Add (+) a range of 0:49
  • Add (+) range of 51:99
This, in turn, returns correct results.  And in our testing, it seemed to specifically be affected rows with a normal balance of C to reverse the sign. 

We reached out to Microsoft, and it appears that this may be a variation of quality report 708796, which deals with issues with ranges in dimensions.  Will keep you posted on any updates I get on the resolution, just thought I might save someone some time hunting around for the cause.  And, yes, I still love Management Reporter :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.