Preparing FRx data for migrating to Management Reporter
Preparing FRx data for migrating to Management Reporter
Upcoming SlideShare
Convergence 2015!Convergence 2015!
Loading in ... 3
1 of 2

More Related Content

Recently uploaded(20)

Preparing FRx data for migrating to Management Reporter

  1. Preparing FRx Data for Migrating to Management Reporter With year-end close behind for most of us, more clients are beginning to consider migrating from FRx to Management Reporter (MR). To help this process along we have compiled a list of steps to help you prepare your FRx data for migration. Management Reporter includes a Migration Wizard to automate this task, but because the two systems are structurally quite different on the back end, it is very important to clean and prepare your FRx reports before migrating them over to Management Reporter. You should carefully follow the entire Migration Guide document to familiarize yourself with the requirements and process, but here are the basic steps you’ll need to prepare your data for migration: 1. Remove unused companies, specification sets, and building blocks (rows, catalogs, columns, trees) from FRx that are not in use or shouldn’t be migrated. 2. Delete the demo companies, any reports pointed at the demonstration specification set and then the demonstration spec set itself. 3. Delete any .f32 files in SysData that are not in use by existing specification sets. 4. Check your rows, columns, trees, and catalogs to identify if any of them are not associated with a report – this means you’ll have to check each one manually. If you want to keep them, you’ll need to create dummy reports to associate them to. If you do not want to keep them, you should delete them as they may cause the migration to fail. Note: in some environments with long lists of building blocks, this could be pretty big job so allow yourself enough time to get this done. 5. Remove any spaces at the beginning of row, column, tree or catalog names. 6. Compact the spec sets for each company. 7. Compact the system database. 8. For GP, you should try to make sure that all the names of your segments are consistent. For example: if GP Company A uses “Account” for segment 1, “Department” for segment 2, you should try to make that consistent across all your GP Companies, and not have them called “Acct” and “Dept” in GP Company B, or “Segment 1” and “Segment 2”. The reason for this is consolidated reporting and consistency between report designs, and even though you’re not being forced to do it it’s the sort of thing you’ll regret later if you don’t clean up before migration. These names are changed in your GP Company Account Format setup. 9. Delete all .g32 files from the SysData directory so there are no old indices around with the old segment names. 10. Log into each remaining company in FRx; this will rebuild the index (G32 file) with your corrected account segment names. 11. Export any existing reports in Management Reporter (migration is going to wipe them, so we strongly advise doing your migration before you do anything else, but it is possible to export ahead of time and import them back in after the fact). This is also a good time to run a SQL backup of your MR tables. If you have FRx installed on individual workstations it is worthwhile to check to see if they are all using the same SysData folder. If they are not, you will need to consolidate all desired reports from any local SysData folder before you begin the clean-up and migration process (see Customer Source for more information or contact ACE Microtechnology for assistance).
  2. For most environments, getting prepared for your Management Reporter migration is not just a few hours of work. With your year-end close completed and financials run for last year, now is a good time to start determining what reports are actually in use in your FRx environment, and to start making plans for selecting which reports remain and identifying the ones that are no longer needed. Below are some tips to make your experience with FRx to Management Reporter migration much easier. Login for MR is done via Windows Authentication/Active Directory. However, once you’re in MR you need to connect to the databases via SQL authentication using your Great Plains login. This is how it works.  The installation documentation tells you to set up a new domain user for Administration of Management Reporter. Since MR uses Windows Authentication for login, you must log into the workstation/server as this new user to log into MR as the Administrator and perform all the setups. This is well documented.  Please note that user licenses are named users, not concurrent users. So a user cannot log in to Management Reporter unless logged into the workstation as one of the named MR users (user type of “Designer”, “Generator”, etc.) as set up within MR by the MR Administrator. Also, remember this: the MR Administrator user takes up one of your “Designer” licenses as Administrator. Be sure to note how many “Designer” licenses you own. In addition to login changes, here are a few more tips that might help with your installation of MR:  If you don’t have Microsoft Office installed (specifically Microsoft Access) on the workstation/server on which you’re installing Management Reporter, you need to install a download or you’ll get an error saying “microsoft.ace.oledb.12.0 not registered”. You will also get this if the wrong version (64-bit versus 32-bit) is installed.  Only one FRx specification set can be migrated to one Management Reporter installation. If you have multiple specification sets, you must first combine them in FRx because any subsequent migrations from FRx to MR will overwrite existing reports. (This is documented in the migration manual.)  If you have multiple company databases, migration can take some time. First, you need to set up all the companies in MR as there is no way to do this en masse. Then, once companies are all set up, migration of reports runs for quite a while.