Accounting Software Custom Report Documentation

 
What are issues you may be having with custom reports?  You may not have any issues with custom reports until you upgrade your system-and there’s the rub.  

If you wait until you need to perform an upgrade to document the purpose and ancillary tools you used to build the report-it’s too late. You can’t recall enough about the purpose of the report or the details of the report to remember what’s truly useful for an upgrade.  

If you wait to record the purpose of the report…the report itself is still upgradeable-but it can take a lot more effort to upgrade the report should any part of the report not work after the upgrade is complete.

Some people (programmer’s mostly) create accounting software reports using complex SQL queries. Still others create easy to understand, short, and useful SQL queries in their reports. Some people (often consultants) write reports straight from tables while other report writers create useful views that make reports run faster and help avoid table joins that can slow down a report.

When writing a report, it is useful to speak to a business analyst first who understands and is willing to document a report’s overall purpose.   This also helps determine if the report should be upgraded.  The developer may have added a report that does exactly what your custom report was intended to do.   Why pay to continue upgrading a custom report, if a standard report can do what you need?

Did someone add an index to a database table to make a report running through millions of records faster?  That index may not move forward with the database upgrade scripts your developer created if the index was not documented and has become forgotten.  Often things like indexes do not stick out to the person performing the upgrade-who often is not necessarily a report writing expert or even a database expert.

If, for example, you spent a lot of time reformatting a report so that it can print on a preprinted form, you may not need to if for example there is a MICR version of that report and you can save yourself some hassle by printing on plain check stock (still need the magnetic toner for MICR checks in this example).  

One of the to-do’s that saves time, if clients are willing to do this, is the following: mock up the report in Excel. If a client is not willing to do this for you, you should mock up the report for them so that what you deliver meets the client’s expectation.   Below is a sample of a custom report mockup for a Dynamics SL client although this custom report could easily be for a Dynamics GP or Intacct user.

Other elements of well-documented reports, as extracted from the Microsoft Surestep Methology documentation are the following:

Your Microsoft Dynamics consultant will guide you through the process of gathering specifications for the report:

• Purpose of the report
• Type of report (i.e., Summary, Detail, Dashboard, etc.)
• Where is the data and what fields will be included?
• Parameters—how do you want to slice the data?
• Features to be used on the report (i.e., Groupings, Toggles, Drill Through, Sub-Reports, Graphs, Summations)
• Formatting—Font, Field formats, Background and Font colors, viewed on web, exporting to Microsoft Office Excel, Microsoft Office Word, or PDF

As a consultant, you want to document these critical elements because, no matter how young you are, these details can leave your short term memory quickly.  The last thing you want to hear your client say is “well YOU wrote the report-you should know what it was for and why it stopped working.”

As a client, you want to ensure that should your consultant leave the area, leave the industry, leave the firm you work with, etc.-you are protected from the chance that should an upgraded report not upgrade right away-that you have options for helping a different resource get you through this.