Custom Development for Microsoft Dynamics GP 10.0 Great Plains

Aug 20
18:03

2007

Andrew Karasev

Andrew Karasev

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

ERP implementation, customization, integration and reporting are always important and hot topics in internet media. Microsoft Great Plains version 10 is in fact successor of Great Plains Software Dynamics and eEnterprise

mediaimage

Microsoft Great Plains version 10 is in fact successor of Great Plains Software Dynamics and eEnterprise (scaled up version of Dynamics,Custom Development for Microsoft Dynamics GP 10.0 Great Plains Articles targeted to large corporate clients).  Dynamics GP 10 has Microsoft Dexterity architecture and Dex is one of the most powerful tools to customize and modify GP – it virtually has no limits in GP programming.  However Great Plains Dexterity is proprietary scripting language and there are not a lot of ready-to-be-hired Dex developers on the permanent and contractual job market.  Let’s look first into MS Visual Studio.Net C# and VB development, as these developers are common on the job market or might be already in IT staff:

  1. eConnect.  This SDK and integration tool replicates GP Dexterity logic on the level of SQL stored procedures (in the case of eConnect SP are encrypted and you can not see their source code).  eConnect allows you to create, modify and delete GP master records (such as customer, vendor, employee, GL account to give you examples) and work transactions (Sales Order Processing Invoice, GL transaction, POP Receiving Entry to name a few).  eConnect is bound to Dexterity architecture and business logic and as such it can not post transactions or batches.  In order to post batches you need Alba Spectrum posting server
  2. Custom SQL Stored Procedures.  Well, if you think eConnect is too heavy and you would like to try SQL scripts instead, you may think twice or three times first, as GP is complex MRP, where direct SQL feeding might be complex and a lot of debugging time required.  If you still think that you are comfortable – please read GP tables structure in Tools->Resource Description->Tables
  3. ADO.Net. We recommend you to design business logic with eConnect and if it doesn’t do the job – with SQL Stored Procedures.   Then in you are MS VS Developer you can call stored procedures from your ADO.Net custom constructions in C# or VB.Net projects
  4. Custom Reporting.  It is natural to find out that Microsoft Dynamics GP ReportWriter doesn’t do expected or unexpected job and you like to extend reporting with either Crystal Reports or Microsoft SQL Server Reporting Services (SRS).  Our recommendation is the following – do not rely too much on Crystal or SRS wizard features, if you plan to create cross modules reports in GP.  Instead design SQL Stored Procedures or SQL Views and base your reports on these SQL constructions: SRS and Crystal Reports are reporting tools, not really and DB querying ones
  5. Rescuing to Great Plains Dexterity.  We think that you should appeal to Dex programmer or GP consultant if you need Dex development, customization upgrade or revision.  If you plan GP customization to be outsourced to Microsoft Business Solution partner, then Dex is not necessarily a bad choice, just an opposite, MBS partner should have Dex programmers in staff and be ready to help you.