Microsoft Great Plains modifications – overview plus implementation and integration options

Microsoft Dynamics GP isn’t exception and in this small article we would like to come through typical GP alterations scenarios

1. Great Plains Dexterity.  This is Integrated Development Environment or IDE with its own programming language sanscript.  Dexterity was designed specially for Great Plains Dynamics in earlier 1990th and this is one of the reasons why Dex is a bit “old-fashioned” and if you are software programmer, you should not expect to begin programming in Dexterity over night.  If you are thinking about creation GP extension for the open market, then you should know that most of the extensions are written in Microsoft Dexterity.  In order to understand the internal side of Dex, please take a look at Dynamics.set file, where all the products are listed.  You begin Dex project by opening Dynamics.dic dictionary and adding or modifying resources in it: forms, reports, windows, fields, scripts, etc.  Some Dex hints – copy Dex.ini from your GP workstation folder to your Dexterity application directory – this will allow you to launch Dex in debugging mode.  Since version 7.0 Dex can call Microsoft COM objects.
2. eConnect.  This tool opens you the access GP work transactions (SOP Invoice, POP Purchase Order, GL record, FA depreciation to name few examples) and master records (customer, vendor, employee, Fixed Asset, General Ledger account).  Initially eConnect was designated to eCommerce developers by opening Sales Order Processing, Inventory and Receivables Management modules, but later on it was extended to cover most of the GP objects.  You can call eConnect from your Microsoft Visual Studio C# or VB.Net projects, as internal logic of eConnect (business objects) is written in MS SQL Server encrypted stored procedures
3. VBA/Modifier.  If you are comfortable with VBA scripting (remember MS Excel modifications?), you can add some logic to existing GP windows, such as SOP Entry screen, where you can put new button with Modifier and then attach VBA script to this field.  If you plan to hit GP database from Modifier-added buttons and field, you should deploy ADO technology, where more likely you will have to hardcode user ID and password.  Modifier allows you to include GP Dexterity sanscript scriplets into the VBA code – this allows you to use Continuum for VBA technology to switch GP modules and manipulate Dexterity objects across your multi-module GP workstation, however this technique is very complex and typically causes expensive version upgrade work
4. SQL Scripting.  One of the most popular routines, where you deploy SQL stored procedures is Electronic Document Interchange or EDI.  EDI has header, body and trailer and you deploy such SQL constructions as CAST, CONVERT to address fixed length fields EDI formatting
5. GP Integration.  Microsoft Dynamics GP Integration Manager should be considered first – it is possible to extend IM with VBA scripting and fields translation table (you can create translation table in Excel and then import it to Integration Manager).  If IM doesn’t do the job, consider eConnect, SQL scripts and Dexterity.  Please, be aware – IM validates GP business logic and this prevents you from all the possible errors in integration.  SQL scripting, in opposite doesn’t validate GP logic and by not doing so – it may compromise your data integrity
6. Modification Upgrade.  Obviously you should expect some complication in GP version update if you deploy custom GP development technologies.  In the case of Great Plains Software Dexterity alternative logic, you should keep Dynamics.dic or Extract.dic with modification scripts in them – Dex developer should be able to upgrade your custom logic.  Talking about Modifier with VBA – if you do not deploy Continuum modules switch tricks, upgrade should be straightforward.  IM typically is GP version proof.  To give you additional version update considerations – Great Plains versions 7.5 and earlier: 7.0, 6.0, 5.5, 5.0, 4.0 and 3.2 were available on alternative DB platforms: Btrieve (later on this DB was renamed into Pervasive SQL Server), Ctree/Faircom, and respectively, if you are on these legacy platforms, your modified logic might deploy programming constructions, specific to these DB platforms only – if you are thinking to upgrade to recent GP version (10.0 or 9.0) – you should come through custom logic porting to Microsoft SQL Server 2005 and 2000
7. GP Reporting tools.  ReportWriter is Dexterity module and it is seamlessly integrated in GP workstation interface and GP security model.  Report Writer reports are stored in Reports.dic.  RW is typically used when you need to modify GP existing reports: SOP Invoice Long Form (place your company Logo is classical example).  Crystal Reports – you should consider good report design practice to offload report record set creation to MS SQL Server stored procedure or SQL view.  SRS or Microsoft SQL Server Reporting Services – in our opinion this tool is competitor to CR and you should be aware to use similar strategy – placing record set selection logic to SQL stored procs.  You can also deploy MS Excel and MS Access to do reporting for GP – please research ODBC connection options for these tools
8. GP modules licensing consideration.  Depending on your GP version – GP professional, standard or business ready, you should be aware that custom modules might require additional purchases, please contact you Microsoft Business Solution partner or MBS ISV
9. Data conversion consideration.  If you are switching from legacy MRP, such as Accpac, MYOB, PeopleSoft, Oracle EBusiness Suite/Financials/Applications, JD Edwards, QuickBooks, PeachTree, MAS 90/2000 to GP, data migration and massage might be required.  We recommend you to keep legacy accounting system for data inquiry and lookup and do not do historical ERP data conversion to Great Plains.  However if historical transactions migration is required, please contact us for the data cleansing quote