Tuesday, November 29, 2016

Multiple Fixed Asset Calendars

So many of you may already be aware that GP now has the capability to handle different calendars for different fixed asset books.  For example, your corporate book could be based on your fiscal year while your tax books could be based on a calendar year.  The calendars are managed in Fixed Assets under Setup, then Calendar.  The system comes with a Default calendar that is assigned to books by default.  However, until you run depreciation, you can change the calendar associated with a book (set up new ones). Once you run depreciation, however, you will have to set up a new book if you want to change the assigned calendar.

With the multi-calendar functionality, dealing with short or long years due to a fiscal year change has become much simpler.  In the calendar setup window, you now have options for these situations:

If the selected year needs to be either short or long, simply mark the option for that year (make sure you have the correct year selected).  Then you need to specify how much depreciation you want to take in the elongated year (100% would be the norm for a 12 period year).  So, for example, if you extended the year by 6 months then you might enter 150%.  Or if you have a short year of 6 months, you would enter 50% of the full year depreciation.  Easy Peasy Lemon Squeezy, right?

I also highlighted the options to build your future years based on the fiscal period setup.  You will want to do this so that they are synced to your new fiscal calendar including the prior year setup, the short/long year, and the future year setup (just make sure you have a future year setup with the normal fiscal year).

Assuming when you make these changes that you are not actually changing the depreciation to be taken in a period that has already been processed in Fixed Assets, there is no need to run a reset on the assets. 

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director 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.

Monday, November 21, 2016

The value of proactive integration logging and error notifications

By Steve Endow

Logging is often an afterthought with Dynamics GP integrations.  Custom integrations often do not have any logging, and while integration tools may log by default, they often log cryptic information, or log lots of events that are not meaningful to the user.

A few years ago I developed a custom RESTful JSON web service API for Dynamics GP that would allow a customer to submit data from their PHP based operational system to Dynamics GP.  They needed to save new customer information and credit card or ACH payment information to Dynamics GP, and they wanted to submit the data in real time.

I originally developed the integration with my standard logging to daily text log files.  While application logging purists (yes, they do exist) would probably criticize this method, my 12+ years of experience doing this has made it very clear that the simple text log file is by far the most appropriate solution for the Dynamics GP customers that I work with.  Let's just say that Splunk is not an option.

The GP integration worked great, and the logging was dutifully working in the background, unnoticed.  After a few months, the customer observed some performance issues with the GP integration, so I enhanced the logging to include more detailed information that would allow us to quickly identify performance issues and troubleshoot them.  In addition to enhancing the detail that was logged, I added some proactive measures to the logging.  I started tracking any delays in the GP integration, which were logged, and I added email notification in case any errors or delays were encountered.

The logging has worked very well, and has allowed us to identify several very complex issues that would have been impossible to diagnose without detailed, millisecond level logging.

Today there was a great demonstration of the value of the integration logging, and more importantly, the proactive nature of the error notification process.

This is an email that was sent to the finance department at 9:18am Central time.  It notifies the users that an error has occurred, the nature of the error, and recent lines from the log to help me quickly troubleshoot the issue.  The user won't be able to understand all of the details, but they will know within seconds that there was a problem, and they will see the customer record that had the problem.

Subject: GP Web Service - Registration Error - PROD

The Dynamics GP Web Service encountered the following errors on 11/21/2016 9:18:22 AM: 

SubmitRegistration for customer Acme Supply Co exceeded the timeout threshold: 15.61 seconds

Here are the most recent lines from the log file:

11/21/2016 09:18:06.505: SubmitRegistration called for customer Acme Supply Co (client, Credit Card)
11/21/2016 09:18:06.505: (0.00) SubmitRegistration - ValidRegistrationHMAC returned True
11/21/2016 09:18:06.505: (0.00) RegistrationRequest started for customer Acme Supply Co
11/21/2016 09:18:06.739: (0.22) ImportCustomer returned True
11/21/2016 09:18:06.786: (0.28) InsertCustomerEmailOptions returned True
11/21/2016 09:18:22.43:        (15.53) Non-Agency ImportAuthNet returned True
11/21/2016 09:18:22.121: (15.60) Non-Agency ImportAzox returned True
11/21/2016 09:18:22.121: (15.60) RegistrationRequest completed
11/21/2016 09:18:22.121: (15.61) SubmitRegistration - RegistrationRequest returned True
11/21/2016 09:18:22.121: WARNING: SubmitRegistration elapsed time: 15.61

Just by glancing at the email, I was able to tell the customer that the delay was due to Authorize.net.  The log shows that a single call to Authorize.net took over 15 seconds to complete.  This pushed the total processing time over the 10 second threshold, which triggers a timeout error notification.

Subsequent timeout errors that occurred throughout the morning also showed delays with Authorize.net.  We checked the Authorize.net status web page, but there were no issues listed.  We informed the client of the cause of the issue, and let them know that we had the choice of waiting to see if the problems went away, or submitting a support case with Authorize.net.

The client chose to wait, and sure enough, at 10:35am Central time, Authorize.net posted a status update on Twitter about the issue.

That was followed by further status updates on the Authorize.net web site, with a resolution implemented by 11:18am Central time.

Because of the proactive logging and notification, the customer knew about an issue with one of the largest payment gateways within seconds, which was over an hour before Authorize.net notified customers.

We didn't have to panic, speculate, or waste time trying fixes that wouldn't resolve the issue (a sysadmin reflexively recommended rebooting servers).  The users knew of the issue immediately, and within minutes of receiving the diagnosis, they were able to adjust their workflow accordingly.

While in this case, we weren't able to directly resolve the issue with the external provider, the logging saved the entire team many hours of potentially wasted time.

So if you use integrations, particularly automated processes, meaningful logging and proactive notifications are essential to reducing the effort and costs associated with supporting those integrations.

You can also find him on Google+ and Twitter

Monday, November 7, 2016

Why Use The System Password in Dynamics GP?

Earlier today I had a client mention the use of the System Password.  I will admit that I tend to toss the concept of the System Password in Dynamics GP in the same pile with User Classes-- used extensively in the past but not so much in new implementations.  For those of you that aren't familiar with it, the System Password in Dynamics GP (Admin Page..Setup..System Password) protects all system menus (Setup, Cards, Reports, etc) with a password.  So to access the system windows, a user is prompted to enter the password (even if they technically have access to the window).

In older versions of Dynamics GP, this was particularly useful since security was optimistic with all users starting out with full access to all windows.  So enacting the System Password was a quick way to protect security level settings.  However, over time the usefulness has faded for a number of reasons...

1. Although there are several critical windows under System, many critical (and damaging) windows are available in the module level setups, routines, and utilities-- so a comprehensive security setup must be in place if you truly want to protect your system
2. The system password is all or nothing, so if you have a user who only needs access to handful of useful windows (like exchange tables, or Smartlist options) then the password will not allow them access
3.  The password is actually easily recoverable (meaning someone with enough knowledge could easily find out what the password is even if they don't have access to the setup window)

I believe that the System Password can give administrators a false sense of security, implying that they have "locked down" the most important aspects of the system when they actually have not.  When Dynamics GP introduced pessimistic (by default, users only have access to log in to the system and nothing else) role and task based security, many existing users kept the System Password in place.  For some,  it provides a simple double-check by prompting the password.  I don't think this is a problem, as long as security is still well-defined and thought through (including the windows accessed through the security menus).  But if you have not considered the points above in your security strategy, I would encourage you to avoid using the System Password as your primary line of defense in your system.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director 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.

Dynamics GP FP: Can't close Table! and FP: Couldn't close table! error messages

By Steve Endow

A Dynamics GP customer contacted me and asked why this error message occurred:

There are a few forum threads on this discussing possible causes, but I thought I would note my experience with this error message.

I see this quite a bit on my numerous Dynamics GP development VMs because of the testing and changes I perform on the machines.  I can easily produce the error with these steps:

1. Launch Dynamics GP and login to a company
2. Open a Dynamics GP window, such as Customer Maintenance
3. Select a record on the GP window, such as a customer, so that you are viewing the customer data
4. Restart the SQL Server service
5. After the SQL Server service is running again, close the Dynamics GP (Customer Maintenance) window (not the whole app)
6. The "FP: Can't close Table!" message should appear
7. Close Dynamics GP completely.  You may get one or more other error messages, and then another "FP: Couldn't close table!" error.  (slightly different wording and Table is not capitalized)

Given this, my initial explanation for this error message is that the Dynamics GP client application lost its connection with the SQL Server.  There may be other causes, but that is always the reason why I happen to see it on my servers.

If you don't think that the SQL Server was rebooted or the SQL service was restarted, then my next guess would be that there was a network interruption between the machine running GP and the SQL Server machine.

If this happens to a GP client running on the SQL Server (as it did with my customer), then that would typically rule out a physical network issue, and I would look into whether SQL was restarted.

There is the possibility of a deeper network configuration issue or an antivirus issue, as discussed in this post:


I personally can't remember the last time I saw the FP error at a customer site, so I can't speak to those as likely causes, but it wouldn't surprise me.

You can also find him on Google+ and Twitter

Thursday, October 27, 2016

Integration Designers and Developers Need Business Context

By Steve Endow

At the GPUG Summit 2016 conference in Tampa 2 weeks ago, I gave a presentation on Dynamics GP system integration design with Tim Wappat.

This is one of my final slides in the presentation:

Out of context, this slide may not seem as meaningful as it is in the presentation, but the idea is that when system integrations are not simplified or designed strategically, they are just glorified data imports that do not help the business strategically.

The next slide offers some goals:

Part of making system integrations successful and more valuable is designing them to meet business requirements.  It isn't just about pushing data into GP.  It's about ensuring that the entire purchasing process, for example, from requisition to PO to receipt to invoice, goes smoothly and with as little manual effort as possible.

To do that properly, the entire team needs to be aware of the context of the system integration and understand the business use cases and requirements.

Friday, October 21, 2016

Two lesser known SQL Server performance tips: Appropriate for Dynamics GP?

By Steve Endow

At the amazing GPUG Summit 2016 mega conference in gorgeous Tampa, his eminence John Lowther, MVP, hosted a session "SQL Administration Made Easy", where he discussed several great tips for simplifying SQL Server administration for Dynamics GP.

Sunny Tampa, October 2016

In his role at nJevity, John and his colleagues have to manage hundreds of SQL Server instances, so they've worked hard to optimize their SQL configurations to work well for Dynamics GP.

As a result of that session, I've kept my eye out for SQL optimization tips, and I have come across two lesser known configuration settings related to SQL Server.

Tuesday, October 18, 2016

Conversations from Summit: What do you call your partner/ISV/VAR/consultant?

As promised, I am continuing to blog about some of the great conversations I had last week at Summit in Tampa, Florida.  This one comes courtesy of multiple discussions over days, with clients as well as with coworkers and a few long time consulting friends.  But, first, a little background on me.  I did indeed become a consultant out of mere happenstance. I needed a job, I knew a little (very little indeed) about software, and took the leap.  Over the years, however, being a consultant has become part of who I am and I find it hard to imagine a different career. I love what I do for two primary reasons (among many lesser ones):

  • I enjoy helping clients get the most out of their systems and processes, becoming a "trusted advisor" that they seek out for advice, guidance, and perspective
  • I like building partnerships with clients, where I learn from them (about requirements, about business, about what keeps them up at night) and I (and my fabulous teammates of course) can impart some of my knowledge to them

The discussions I had last week at Summit circled around the client relationships I enjoy most.  And we kept coming back to the term "partner".  I love it.  It is my preferred term.  Because it suggests, obviously, a partnership of give and take and mutual benefit.  Not simply a business exchange of services for money (which is why terms like "vendor" or "contractor" don't appeal to me).  Of course, I am not talking about a word game but more the nature of the relationship between consultant and client.

Of course we have to start with a solid base of product knowledge and experience, but the truly great client/consultant partnerships extend in to so much more.  Where we as consultants can benefit clients in ways that extend beyond how to configure a module or cut an AP check.  And on the client side, they can contribute greatly to our understanding of their business, industry, and needs...which makes it that much easy (and dynamic) to serve them well.

So I challenge you to look at your relationship with clients or with consultants (depending on your role), and see how you can contribute to making it a partnership. One way to look at it is to make note of how you refer to them (either client or consultant), is it in a defensive/combative way (preparing for an issue)? Is it distanced, lacking in trust? And then commit to moving towards a partnership-- sometimes that means a "clearing the air" conversation, or discussing specific expectations from both sides to improve the relationship, or simply reaching out regularly with questions that extend beyond error messages.  On both sides, it requires a fair amount of good faith, trust, and expertise. Or at least it does in my opinion, do you agree or disagree?

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director 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.