(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 ﬁnancial periods. Financial period balances control how ﬁnancial statements are presented. Once ﬁnancial statements are complete they shouldn’t change except in very speciﬁc, controlled circumstances. If a ﬁrm doesn’t properly control access to ﬁnancial periods the company’s frustration of trying to compare results to a moving target, continually changing ﬁ nancial statements can cause Securities and Exchange Commission (SEC) issues, audit problems, and a loss of conﬁdence in the ﬁrm’s ﬁnancial reporting.
The way to control access to ﬁnancial periods in Dynamics GP is to close ﬁnancial 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 ﬁnalizing ﬁnancial statements.
Typically, companies have the current period open for transaction entry. As transactions arrive for the next period, ﬁrms 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 ﬁ scal period to prevent further transactions.
In this recipe, we will look at the process to close ﬁscal periods in Dynamics GP.
How to do it…
To close a ﬁscal period in Dynamics GP:
- Select Administration from the Navigation Pane. Select Fiscal Periods under the Setup and Company sections on the Administration Area Page.
- 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:
- 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 ﬁnancial statements.
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.
Closing ﬁscal 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 ﬁnish 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:
- In the Fiscal Periods Setup window click on Mass Close.
- Set the Series to Purchasing.
- Scroll to Payables Trx Entry and select the checkbox next to it:
- Click on Save to close the period for that transaction type.
- 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 ﬁ 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 ﬁeld.
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 signiﬁcantly. 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 ﬁeld to a more manageable one thousand.
How to do it…
To get control over AutoComplete entries:
- Select Home from the Navigation Pane. Select User Preferences in the Shortcut Bar.
- Click on the AutoComplete button.
- Set Remove Unused Entries After to 60 days. Click on OK to ﬁnish.
- Change the Max. Number of Entries to Store per Field setting to 1,000:
- 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.
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 ﬁrm wants to globally set the number of days to remove unused entries after and the maximum number of entries to store per ﬁeld, they can do that by executing the following code in SQL Management Studio against the Dynamics database:
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 ﬁeld 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 ﬁrms do keep history, and in that case Paid Transaction Removal moves Accounts Receivable transactions to history. This signiﬁcantly 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-Sufﬁcient 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 efﬁciency 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 ﬁrms set this date 30 to 90 days before the current date. I’ve seen ﬁrms use time frames of six months or longer when they have signiﬁcant issues with misapplied payments. The key to an efﬁcient 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 efﬁcient. In this recipe we’ll look at how to process Paid Transaction Removal.
To ensure that history is being kept prior to running Paid Transaction Removal:
- In Dynamics GP select Sales from the Navigation Pane. Select Receivables under the Setup section on the Sales Area Page.
- Select the Print Historical Aged Trial Balance checkbox to ensure that transaction history is kept regardless of other customer history options.
- Click on OK to save:
How to do it…
To run Paid Transaction Removal in Dynamics GP:
- In Dynamics GP select Sales from the Navigation Pane. Select Paid Transaction Removal under the Routines section on the Sales Area Page.
- The process can be limited to certain customers and classes but most ﬁrms run the process for all of their customers.
- In the sample company change the Cut Off date next to NSF to 2/12/2017.
- This cutoff date applies to all of the items from NSF down to the next cutoff date. This includes:
- Paid Transactions
- Change the cutoff date next to Checks to 2/12/2017.
- Select the Print Register checkbox to print the transactions being moved to history:
- Click on Process. Choose to print the report to the screen and click on Yes to remove paid transactions.
- A report will print with the speciﬁ 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.
This process behaves differently for companies tracking receivables using the Balance Forward method.
For companies using the Balance Forward balance type there are only two aging buckets— current and non-current. Most ﬁrms do not use the Balance Forward setting for receivables. For those ﬁ 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:
- Select the Balance Forward Consolidation checkbox.
- Deselect the other checkboxes and click on Process: