Dynamics GP: Challenging Data Conversion Projects

Feb 15
08:18

2010

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

We saw large number of Great Plains customers, initially purchasing software from one Dynamics GP reseller and then having to switch GP VAR due to failed data migration from legacy ERP system to Great Plains. There might be various reasons, and among them the fact - Corporate ERP data conversion requires technical skills and often in-depth consultant expertise in table structure, advanced SQL queries and fixes.

mediaimage
When you are setting implementation requirements,Dynamics GP: Challenging Data Conversion Projects Articles it is not in general the perfect idea to move "all" from your legacy accounting to the new ERP system - instead it is a way better to agree on minimal conversion or try to find reasonable balance on what should be converted and what should be left in the legacy application for future inquiries.  If you must have complex data conversion, see the details below:
1. Integration Manager.  We recommend to consider IM as the first tool to consider.  If Integration Manager doesn't populate something - there should be a reason why.  For example, if you are trying to migrate Sales Transactions History and IM doesn't integrate historical (or also sometimes referred as posted) transactions, integrate work transactions into SOP module and then post them from there with historical dates.  This example gives you the idea on who should be involved in Dynamics GP data migration - Great Plains functional consultant (who knows transaction posting from SOP to RM and General Ledger modules in our case) and IM programmer.  If you are moving huge number of transactions from your legacy Corporate ERP application, consider deploying Advanced ODBC data sources in IM - these methods should allows you to work with SQL select statement s and union constructions in ad-hoc legacy DB querying (for SQL programmer - you can deploy SQL cross platform views)
2. SQL converted data modifications.  When all what you need is transferred into Dynamics GP company database and you do want to alter converted data a little bit (change transaction date, customer name, comments, etc) - you can use SQL update statement.  We do not recommend direct SQL insert, as all you need should be doable via Integration Manager (where all GP business logic is validated and you cannot compromise data integrity).  You can also use SQL select statement with summaries to compare balances in GP and in legacy ERP tables (or you can run Great Plains report, if the one you need exists).  Converted data fixing is obviously more dangerous, comparing to Integration Manager remigration - if remigration is possible and your time budget permits, we would rather recommend it versus SQL touches
3. Ongoing data import to Great Plains.  If you are looking for ecommerce, EDI, or similar ongoing data feeding options - consider eConnect (for real time integrations) or Integration Manager (for quasi real time or batch mode integrations).  eConnect is Software Development Kit, which allows you to include its libraries in Microsoft Visual Studio C#, VB.Net application for real time document creation in GP (typically in eCommerce scenarios).  IM could be scheduled to run every twenty or so minutes to imitate quasi real time integration to Dynamics GP
4. What to do if your Dynamics GP implementation failed due to poor data conversion?  Well, ask for second opinion.  Give us a call 1-866-528-0577, help@albaspectrum.com