Microsoft Dynamics GP 2013 Implementation
上QQ阅读APP看书,第一时间看更新

Identifying reporting needs

Reporting is often looked at as a by-product of an implementation, something that may need to be tweaked after the implementation is completed. Your implementation will be much more successful if you identify the reporting needs upfront and include reporting in your planning. There are three types of reports to consider: financial statements, management reports, and business forms. Let us look at each of these in more detail.

Financial statements

Financial statements typically are run monthly, once the month is closed. Some companies also like to see interim financial statements throughout the month. The basic financial statements are Balance Sheet, Profit and Loss Statement (also called P&L, Income Statement, or Statement of Operations), and Cash Flow.

Most companies have many variations of financial statements, especially the Profit and Loss Statement. For example, NJW may want to have an overall company P&L as well as a separate P&L for their three revenue centers: hardware, software, and services. In addition, they would like to have an actual versus budget P&L once the budgeting functionality is in place.

As part of your planning, identify the following:

  • A list of all financial statements needed.
  • A sample of each financial statement, even if it does not exist today. An example in Excel or even sketched out manually is fine.
  • A list of users that will need to run financial statements.
  • A list of users that will be creating or modifying financial statements. (In many companies, this consists of only one or two people).

Pay particular attention to the variations of P&L's needed and also watch out for multiple control accounts on Balance Sheets. Both of these may cause you to change how you implement Dynamics GP, or lead to some further discussion and possible changes in accounting practices or reporting.

Multiple control accounts on Balance Sheets

A control account is a General Ledger account that holds the summary of a subledger. The most common examples of control accounts are Accounts Payable, Accounts Receivable, Inventory, Cash, and Fixed Assets.

Dynamics GP has modules that are subledgers for each of these control accounts. However, Cash and Fixed Assets are the only two modules that allow for easy reconciliation of the subledger to multiple General Ledger accounts. While it is possible to have multiple Accounts Payable (AP), Accounts Receivable (AR), and Inventory accounts, the setup, reconciliation, and reporting for these can sometimes get very complicated.

If multiple control accounts for AP, AR, and Inventory are currently used, find out why. If the answer is "that's how we have always done it", then you have a good case for suggesting combining all the control accounts into one. It also may be that previous systems required the use of multiple control accounts to enable separate subledger reporting for them. Dynamics GP can most likely fill that requirement with existing subledger reports, thus eliminating the need for the multiple control accounts in the General Ledger.

For example, AR or AP aging and inventory stock status reports can be filtered by a Class ID assigned to each customer, vendor, or inventory item. So, if the NJW company needs to print separate reports for the hardware versus software inventory, this can all be handled in the Inventory subledger, with only one GL Inventory account. However, it may be that NJW needs to provide a monthly Balance Sheet to their bank, showing the hardware and software inventory as separate items. In that case, the answer may be that multiple control accounts are needed and should stay the way they are on the current financial statements. Make sure you keep this in mind as you continue planning.

Variations of Profit and Loss Statements

There are two methods of grouping details on P&L's. One is to show separate line items for major groupings. For example, NJW sells hardware, software, and services. Therefore, they may want to see sales and costs on all P&L's broken out into these three categories:

The alternative to this is having one summary report:

And then have individual sub-reports for each category:

Understanding all the variations required for reporting will help you plan the implementation, so spend some time talking with the management team to gather these requirements.

Management reports

Management reports are just about every other report you can think of besides financial statements. Typical examples are Receivables Aging, Payables Aging, Inventory Stock Status, General Ledger Trial Balance, and Monthly Sales Summaries—by customer, salesperson, item, or by item type. Commission reports and lists of open customer orders or open purchase orders are also frequently requested.

These reports vary greatly from company to company and often will be a source of frustration for users. For example, sales commission reports commonly take hours to put together each month. There will also be wish-list reports that have been identified as helpful, but that currently no one knows how to obtain. Identifying these reports will be more challenging than the financial statements. Talk to the Accounting and Operations resources on your team about these and possibly spend some time interviewing end users to ask what reports would help them do their jobs more effectively.

Some management reports will be standard in any accounting package. However, you should not assume that Dynamics GP will have built-in reports that are the same as what your previous system had. We have seen many users coming from other systems be surprised at what is or is not included out-of-the-box in Dynamics GP.

As part of your planning, identify the following:

  • A list of all management reports needed.
  • An example of each report, even if they do not exist today. An Excel mockup or even something sketched out manually is fine.
  • Any logic for these reports. For example, when there are lending relationships with banks, a company may need two different versions of their AR Aging report—one for the bank, aged by invoice date and a different one for internal use aged by due date.

Business forms

Business forms is a common name for anything a company sends routinely to customers and vendors, and these typically have some more stringent requirements for formatting. Common examples of business forms are invoices, packing lists, picking tickets, customer statements, purchase orders, and payables checks. Some companies may only need a few forms, while others will need many business forms, with some variations of each one.

Companies will usually have a very clear idea of exactly how their business forms should look. Most of these will need to have the company logo; some companies will want everything in a particular font. Often, companies can use the Dynamics GP implementation as a chance to change things they are not entirely happy with on their business forms.

As part of your planning, identify the following:

  • A list of all business forms and the variations that are needed.
  • A sample or mockup of each report, even if they do not exist today.
  • Any logic for these forms. For example, currently NJW has two different invoices, one for hardware and software, and another for services. They make sure to never put both types of items on the same invoice. The service invoices have detailed descriptions of the work performed. The hardware and software invoices have serial numbers and/or agreement numbers when applicable.