Maintaining Microsoft Dynamics GP 2010

8 min read

(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


Please enter your comment!
Please enter your name here