Maintaining Microsoft Dynamics GP 2010

(For more resources on Microsoft, see here.)

Preventing entry of wrong dates by Closing Periods

An important step in maintaining any accounting system is controlling access to financial periods. Financial period balances control how financial statements are presented. Once financial statements are complete they shouldn't change except in very specific, controlled circumstances. If a firm doesn't properly control access to financial periods the company's frustration of trying to compare results to a moving target, continually changing fi nancial statements can cause Securities and Exchange Commission (SEC) issues, audit problems, and a loss of confidence in the firm's financial reporting.

The way to control access to financial periods in Dynamics GP is to close financial periods that are not being used. In some systems, closing a period is a time-consuming and irreversible process. This is not the case with Dynamics GP. Dynamics GP provides an easy way to close periods and reopen them for adjustments prior to finalizing financial statements.

Typically, companies have the current period open for transaction entry. As transactions arrive for the next period, firms typically open the next period as well to allow entry of next period's transactions. This leaves two periods open at around month-end close but otherwise, only one period is open at a time. Once a period is complete it's important to close that fi scal period to prevent further transactions.

In this recipe, we will look at the process to close fiscal periods in Dynamics GP.

How to do it...

To close a fiscal period in Dynamics GP:

  1. Select Administration from the Navigation Pane. Select Fiscal Periods under the Setup and Company sections on the Administration Area Page.
  2. Select the checkbox next to the period and module to close. Typically, the Financial series, which includes the General Ledger, is the last series to be closed:
  3. Maintaining Microsoft Dynamics GP 2010

  4. Deselecting the checkbox under a series reopens the period for subsequent adjusting of entries.

How it works...

Closing the period is an important monthly maintenance procedure. It is critical to preventing transactions from posting in the wrong period and it's an important step to ensuring the correctness of the financial statements.

There's more...

By default, the Fiscal Periods Setup window controls posting transactions to a period for all transactions in a module. Sometimes though, the module level is too high and companies need the ability to allow certain types of transactions to post while preventing others.

Mass Close

Closing fiscal periods based on series is easy. However, there are times when a company isn't ready to close an entire series, but does need to prevent the posting of certain transaction types. This can be accomplished using the Mass Close button on the Fiscal Periods Setup window.

For example, if accounts payable needs an extra day to finish cutting checks but the company wants to prevent the entry of new payable vouchers in the period, the Mass Close button presents a list of all of the posting transaction types and allows a user to close the period, not for a series, but for one or more transaction types within that series.

To demonstrate closing only a particular transaction type:

  1. In the Fiscal Periods Setup window click on Mass Close.
  2. Set the Series to Purchasing.
  3. Scroll to Payables Trx Entry and select the checkbox next to it:
  4. Maintaining Microsoft Dynamics GP 2010

  5. Click on Save to close the period for that transaction type.
  6. Notice that the entire series is marked as closed. There is no visual cue that only part of this module has been closed.

Improving performance by adjusting AutoComplete settings

Microsoft Dynamics GP provides AutoComplete functionality that remembers previous entries and displays them to users during subsequent data entry. Users can select the appropriate item without having to type the entire text. This is a great feature but the entries are stored per user and per fi eld. This means that each time the system saves a vendor number that has been keyed it's saved as one entry for that user. By default, Dynamics GP is set up to hold ten thousand entries, per user, for each field.

As you can imagine, over a long period of time, and in organizations with heavy entry volume, the number of entries can build up slowing down AutoComplete performance significantly. Additionally, the number of choices presented to users can become unwieldy. For this recipe, we will look at a two-part solution to this problem. First we will set up a maintenance routine to clean out any entries not used over the last sixty days and then we will reduce the number of results being saved per field to a more manageable one thousand.

How to do it...

To get control over AutoComplete entries:

  1. Select Home from the Navigation Pane. Select User Preferences in the Shortcut Bar.
  2. Click on the AutoComplete button.
  3. Set Remove Unused Entries After to 60 days. Click on OK to finish.
  4. Change the Max. Number of Entries to Store per Field setting to 1,000:
  5. Maintaining Microsoft Dynamics GP 2010

  6. The new settings will take effect once the user logs out and back in

How it works...

Companies can help prevent system slowdowns by controlling the volume of entries that Dynamics GP uses for AutoComplete. This setting is a per user setting so each user needs to make the change for their own login.

There's more...

Administrators can change this setting for all users with an SQL command.

Making the change for all users

Some users obviously make greater use of the AutoComplete feature than others. Consequently, companies may not want to set all users to the same settings. If a firm wants to globally set the number of days to remove unused entries after and the maximum number of entries to store per field, they can do that by executing the following code in SQL Management Studio against the Dynamics database:

Update Dynamics..sy01402
Set syUSERDFSTR='TRUE-60-1000'
Where syDefaultType=30

The middle line turns AutoComplete on with the TRUE setting, removes unused entries after 60 days, and sets the maximum number of entries to store per field to 1,000.

Cleaning up Accounts Receivable with Paid Transaction Removal

An important maintenance item that is often overlooked is Accounts Receivable Paid Transaction Removal. Perhaps it is overlooked because the name is somewhat misleading. Paid Transaction Removal only removes receivable transactions for companies that are not keeping receivables history. Most firms do keep history, and in that case Paid Transaction Removal moves Accounts Receivable transactions to history. This significantly reduces the number of transactions to be processed by Dynamics GP when running Accounts Receivable Aging and it can provide tremendous speed improvements to the aging process because the aging routine no longer has to work through the pile of completed paid transactions.

Once Paid Transaction Removal is run companies can no longer unapply payments to a receivables invoice. Additionally, once a check is moved to history via Paid Transaction Removal, it can no longer be marked as Non-Sufficient Funds (NSF). With these restrictions it's commonly recommended that the Paid Transaction Removal process be run with a date in arrears. A misapplied invoice will typically be picked up within an invoicing cycle or two. Using a delay provides a buffer to allow for easy corrections of recent transactions while still providing the efficiency of removing completed transactions.

Companies typically run Paid Transaction Removal monthly. The routine is set to remove paid transactions older than a set date and most firms set this date 30 to 90 days before the current date. I've seen firms use time frames of six months or longer when they have significant issues with misapplied payments. The key to an efficient AR aging process isn't in the interval used; it is in running the process regularly to control the number of open receivables that keeps the AR aging process efficient. In this recipe we'll look at how to process Paid Transaction Removal.

Getting ready

To ensure that history is being kept prior to running Paid Transaction Removal:

  1. In Dynamics GP select Sales from the Navigation Pane. Select Receivables under the Setup section on the Sales Area Page.
  2. Select the Print Historical Aged Trial Balance checkbox to ensure that transaction history is kept regardless of other customer history options.
  3. Click on OK to save:
  4. Maintaining Microsoft Dynamics GP 2010

How to do it...

To run Paid Transaction Removal in Dynamics GP:

  1. In Dynamics GP select Sales from the Navigation Pane. Select Paid Transaction Removal under the Routines section on the Sales Area Page.
  2. The process can be limited to certain customers and classes but most firms run the process for all of their customers.
  3. In the sample company change the Cut Off date next to NSF to 2/12/2017.
  4. This cutoff date applies to all of the items from NSF down to the next cutoff date. This includes:
    • NSF
    • Void
    • Waived
    • Paid Transactions
  5. Change the cutoff date next to Checks to 2/12/2017.
  6. Select the Print Register checkbox to print the transactions being moved to history:
  7. Maintaining Microsoft Dynamics GP 2010

  8. Click on Process. Choose to print the report to the screen and click on Yes to remove paid transactions.
  9. A report will print with the specifi c transactions moved to history by the customer.

How it works...

Regularly running Paid Transaction Removal reduces the workload on Dynamics GP when processing receivables aging. Reports based on open receivables transactions will also run faster. All of these improvements allow receivable employees to spend less time waiting for information and more time collecting open invoices.

There's more...

This process behaves differently for companies tracking receivables using the Balance Forward method.

Balance Forward

For companies using the Balance Forward balance type there are only two aging buckets— current and non-current. Most firms do not use the Balance Forward setting for receivables. For those fi rms that do use the Balance Forward method the Paid Sales Transaction Removal window is used to consolidate balances and move current transactions to the non-current bucket.

To consolidate balances for Balance Forward customers:

  1. Select the Balance Forward Consolidation checkbox.
  2. Deselect the other checkboxes and click on Process:

Maintaining Microsoft Dynamics GP 2010

(For more resources on Microsoft, see here.)

Providing correct tax information by Updating 1099 information

A common problem arises at year end in the United States with vendors that were not properly set up as 1099 vendors. 1099 vendors are vendors who are required to be sent a 1099 tax form from the company. The types of transactions that can require a 1099 include rent, legal payments, and contract labor among others. The requirement is broad enough that most vendors who are not incorporated (proprietors, partnerships, and so on) may be due a 1099 if they are paid more than six hundred dollars in a year.

Recent changes to the U.S. law have dramatically increased the number of 1099 forms that will need to be sent in the future. Essentially, all payees who receive more than $600 in payments will need to receive a 1099 in the future. As part of this legislation the fi nes for 1099 reporting errors have also been increased signifi cantly. Correctly reporting 1099 information is more important than ever and this recipe can save companies a lot more than just lunch money.

The specifics of 1099 requirements often meant that vendors were incorrectly set up and the amounts required for tax reporting on 1099 forms were not collected for that vendor in Dynamics GP. The preferred solution is to use SmartLists or built-in reports to determine what the correct 1099 amount should have been. These amounts are then added to the vendor record so that they will print correctly on the 1099 form.

The specifics of figuring out what should be on a vendor's 1099 form are beyond the scope of this recipe. For this recipe, let's look at how to serve up correct 1099 forms in the sample company once the right amounts have been obtained.

How to do it...

To correct 1099 amounts for a vendor:

  1. Select Purchasing from the Navigation Pane. Select 1099 Details under the Cards section of the Purchasing Area Page.
  2. In the Vendor ID field enter COMPUTER0001 and click on Tab .
  3. Set the Tax Type to Miscellaneous and the Display to Month.
  4. Change the Month to December.
  5. In the Amount field, next to 7 Nonemployee Compensation, key in $1,100.00 to represent the 1099 amount:
  6. Entries must be made at the Month level. Selecting Year won't allow users to make an entry in the amount field. When catching up vendor 1099 amounts companies can make an entry per period but most simply put the catch-up amount in the last month of the year.

How it works...

Maintaining 1099 vendors and amounts is something that many companies do a poor job with. This maintenance recipe will at least correct things for year end and provide correct 1099 amounts for tax filing. Ultimately though, better vendor setup is the answer to reducing this maintenance requirement.

There's more...

A better option to correcting 1099 amounts at year end is to get vendor setup right in the first place.

1099 Vendor Setup

The preferred alternative to correcting 1099 amounts is to improve vendor setup. Often the problem is that vendor setup is rushed and insufficient information is provided. As a result of this, vendor's requirement for a 1099 comes to light later, after invoices have already been processed.

The key is to get control of the vendor process by placing all new vendors on hold until the vendor record contains specifi c information such as the vendor's tax ID number, whether or not this is a 1099 vendor, and the type of 1099 expenses to be incurred. Most of the required information can be gathered by obtaining a completed W-9 form from the vendor. Vendors are happy to provide the necessary documentation if they know up front that their invoice won't be paid without it. Communicating and enforcing this policy is a step to better 1099 reporting.

Even with proper vendor setup discipline, it is possible for someone to erroneously remove the 1099 amount from a payables voucher. However, the number of vendors that would need to be corrected in this case would be less and this maintenance recipe becomes a simple year-end process, not an onerous one.

Maintaining updated code by rolling out Service Packs with Client Updates

Using service packs for Dynamics GP is an important part of maintaining the system. Service packs provide bug fixes, close potential security holes, and improve system performance. Some service packs, known as Feature Packs, even add new functionality. Service packs should normally be tested on a test server prior to applying them to a production environment. Service packs can negatively affect modified forms, modified reports, customizations, and third-party products so it's important to test them first.

Once service packs are tested they should be applied to the company's server first. After that comes the burdensome process of installing service packs on each user's computer as users won't be able to log in after the service pack has been applied to the server. A better alternative is to use the Client Update functionality for service packs in Dynamics GP 2010.

That's right; Dynamics GP provides a mechanism to make the service packs available on the server. When a user without the appropriate service pack logs in Dynamics GP notifies the user, downloads the service pack from the server, and installs it on the user's machine, all without the intervention of an administrator. As rolling down service packs is the focus of this recipe, let's look at how to do it.

Getting ready

Prior to rolling out service packs to users:

  1. Download the service pack from CustomerSource ( and save it to a network location accessible to Dynamics GP users.
  2. Apply the service pack to the server and test to ensure that the system operates as expected.
  3. For our example, we'll assume that this is service pack 2 and that we've downloaded it to a network location as \\myserver\GPServicePacks\ MicrosoftDynamicsGP-KBXXXXX-v11-ENU.msp.

How to do it...

To roll out a service pack to Dynamics GP users:

  1. Select Administration from the Navigation Pane. Select Client Updates under the System section of the Administration Area Page.
  2. In Update Name enter Service Pack 2 to separate this from other updates
  3. Select the checkbox marked Update clients at next use.
  4. Enter the update location as \\myserver\GPServicePacks\ MicrosoftDynamicsGP-KBXXXXX-v11-ENU.msp.

    Note that this requires the location to be formatted using a Universal Naming Convention (UNC). A typical c:\mylocation style path will not work even though the lookup button allows that:

  5. Click on Save to activate the rollout. Users will get a prompt to start the update the next time they log in.

    Companies can set up the client update during testing and simply refrain from selecting the Update clients at next use checkbox. This saves the update until testing is complete. After that, it's easy to select the checkbox and start updating clients.

How it works...

Rolling out services packs automatically is a huge time saver in a traditional desktop environment. Administrators need to properly plan and communicate that clients will be updated as the application of a service pack can be very time consuming. A lot of complaints result when users show up on a Monday morning expecting to be productive only to find that they have to wait an hour or more for a service pack to apply.

This feature isn't as important in a Citrix or Terminal server environment. As only the Citrix or Terminal servers need to be updated in addition to the SQL Server components, the Client Update feature doesn't provide a big time saving over manual updates.

There's more...

It's also important to avoid the common error of removing a service pack from the server without deselecting the Update clients at next use checkbox.

Service Pack Errors

It's not unusual for someone to delete a service pack installation file from the server without deselecting Update clients at next use. When this happens Dynamics GP displays an error the next time that a client computer without the service pack installed tries to log in. In that scenario either the service pack installation file needs to be returned to the download location or the Update clients at next use checkbox should be deselected and the client computer updated manually:


This article included recipes for an administrator or power user to help maintain Dynamics GP.

Further resources on this subject:

You've been reading an excerpt of:

Microsoft Dynamics GP 2010 Cookbook

Explore Title