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.

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: 10.0.0.66 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.

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.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

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:

https://community.dynamics.com/gp/b/dynamicsuniversitygp/archive/2013/11/04/fp-couldn-39-t-close-table-one-setting-that-may-end-random-disconnects-to-your-gp-databases


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.

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.

You can also find him on Google+ and Twitter

http://www.precipioservices.com