Migration to Management Reporter from FRx

Does the Release of Management Reporter 2.0 Affect You?

With the release of Microsoft Dynamics 2010, Microsoft has also released their new reporting tool, Management Reporter, to replace FRx 6.7. While Microsoft is requiring all new Dynamics GP 2010 customers to utilize Management Reporter, existing users running prior versions of Dynamics GP can continue to use FRx 6.7, even with an upgrade to Dynamics GP 2010.  Microsoft will continue to support FRx 6.7 through the end of the Dynamics GP 10.0 lifecycle.

Management Reporter has several new features which gives it an edge over FRx. It allows for windows authentication, version management of the reports and supports reporting on dimensions based data such as departments, locations, and cost centers.  Additionally multicurrency reporting in Management Reporter is now driven from existing rate tables within Dynamics GP 2010, eliminating the need to maintain separate rate tables to facilitate this kind of reporting.

Additional features that users have been asking for in FRx, such as column breaks, undo and redo function and the ability to import images into the header and footer of the reports are now available in Management Reporter.

There are a few limitations of Management Reporter that should be considered in making the decision to upgrade, however there are available workarounds to mitigate these shortcomings.

With all of its new features Management Reporter still utilizes many of the same concepts as FRx enabling users to apply their FRx knowledge as they transition to Management Reporter. It has a similar look and feel for the setup of rows, columns and reporting trees with a slight variation of terminology.  The dropdown boxes in the row and column definitions will provide selection FRx users are familiar with and have a few new selections of added functionality. A migration wizard is available to convert existing row, column, tree and report definitions, report catalogs, account sets and company information to new Report Definitions in Management Reporter, making the transition fairly seamless.

7 Questions when Integrating a Shopping Cart to Dynamics GP

We often get asked about integrating various web shopping carts (ecommerce sites) to Dynamics GP which requires a number of very important discussions before identifying the effort to configure such integrations. The following are 7 relevant topics that must be clarified first:

1) What vehicle(s) does the Shopping Cart provide to export the Sales Order information?

  • A Web Services API which gives us direct access to the SO data programatically? Or,
  • Can the Shopping Cart write new Sales Order info to a file (CSV, XML, SQL Table?) that we can grab programatically (from an FTP site, for example)? Or,
  • Is someone going to have to manually download a file (CSV, XML?) that contains the new Sales Order information for a given period?

2) Customer records?

  • Does the customer need a GP Customer Card for each new Customer that signs-up in the Shopping Cart? If so, we need a consistent rule to map Customer Numbers between the two applications.
  • Will the customer enter all Shopping Cart orders using a generic GP Customer (such as: WEBCUSTOMER)?

3) Item records and Pricing Info?

  • Will the Item Numbers used by the Shopping Cart be exactly the same as the GP Item Numbers? If not, we need to come up with a consistent way to map the two.
  • Is the Unit Price charged to the Web customer clearly expressed in the Sales Order export? If not, we need to make sure that the GP Price Lists are consistent with the Shopping Cart pricing scheme.

4) Payment Info?

  • Are the Shopping Cart Sales Orders entered in GP as fully paid? Or,
  • Are the Shopping Cart Sales Orders entered in GP with a Credit Card Book Transaction to be settled later inside GP (once the order is shipped) by Nodus’ Credit Card Advantage (CCA)? If so, we need to confirm that the two systems work in a compatible way (that is: that the Shopping Cart’s Book transaction and corresponding Authorization codes are compatible with CCA’s Sale transaction inside GP.)

5) Do we need to export anything (such as Tracking Numbers) from GP back to the Shopping Cart? If so, what vehicle(s) does the Shopping Cart provide to import data?

6) Frequency of the Import / Export execution

  • If we want automatic execution (if available depending on the answers to topic 1), with what frequency?

7) Notifications and Logging

  • Do we want any email notifications triggered along the way?

Automating Allocation of Expenses to Projects in Dynamics GP

Many companies (including government contractors) must prepare budgets as well as report actual revenues & expenses down to the level of individual projects, but do not wish to incorporate projects into their chart of accounts structure (the preference being to maintain that information in a sub-ledger). One of the associated challenges is that allocated expenses frequently need to be charged to projects, but some of the best allocation tools in Dynamics GP are limited to working only at the level of GL accounts.

For those clients using Dynamics GP’s Project Accounting module, GP offers a “Project Allocation” option, which allows users to re-assign certain expenses from one project to multiple other projects. This functionality allows expenses from one project (derived from timesheet entry, purchases, etc.) to be allocated out to other projects, based on either a fixed percentage or based on units or amounts from a specified basis (cost category) on the projects to which the expenses are to be allocated.

Many clients prefer to track project data using Dynamics GP’s Analytical Accounting module, in part because of ease of use and compatibility with financial reporting tools. For those companies, Tridea Partners has developed an add-on application that works in a manner similar to the “Variable Allocations” functionality in Dynamics GP. The difference is that this new application allows users to base their allocations on the balances (or period net change) in combinations of GL accounts and AA codes. Furthermore, the resulting allocated amounts can be posted to combinations of GL accounts and AA codes. It provides a means of performing a month-end allocation of expenses to projects based on actual expenses that have been incurred and assigned to projects during the course of the month. The user simply defines the combination of accounts/AA codes that will be used as drivers for the allocation, and then associates them with the destination posting accounts/AA codes. The program will calculate the amount to be allocated, and automatically post an entry with both the allocation-out and the corresponding allocations to the various projects.