Microsoft Dynamics GP, or how it was known in the past – Great Plains Dynamics has several customization tools, including Great Plains Dexterity.
This is in essence GP architecture, specially created in earlier 1990th to provide Great Plains Dynamics ERP product some level of neutrality – from those days computer platforms (such as MS Windows, Mac OS, Solaris, Unix to be examples) and database vendors (Oracle, Btrieve, earlier Microsoft SQL Server to name a few). Neutrality and its reasonable performance those days was typically achieved by programming so-called Shell in one of the cross-platforms programming languages (in the case of Dexterity it was C). Modern GP Dexterity has its Integrated Development Environment with graphical form, tables, reports and other objects designer, plus it has its own proprietary programming language Sanscript. Before you dive into programming itself, it is important to understand such concepts as Dexterity Dictionary, alternate and new Dex forms, and reports (here you do not have an option to modify existing table, if it was not introduced in your customization, but is taken directly from main dictionary Dynamics.dic or from another Dynamics GP ISV add-on product dictionary, where you do not have control over the source code). Let’s review some techniques, attributed to Dexterity coding:
1. Dexterity triggers. If you want your Dexterity custom product to be friendly to most or all the other Dexterity dictionaries, instead of altering existing form or report, you think if the same goal is possible through field or even driven triggers. To give you good example – in Dynamics GP Sales Order Processing Transaction form is famous to be customized in large number of Dynamics GP ISV products. If you alter SOP Transaction form (by taking it directly from Dynamics.dic dictionary) – your Alternate SOP Transaction form will disable potentially other add-ons, where this form is also altered. If what you need to do is to set some restrictions on one or several fields in this form – you may do it in the triggers (this triggers are not physically located on the form itself, instead they are registered when user logins Great Plains client interface)
2. SQL Stored Procedure call outs from Dexterity, versus Dex traditional cursor driven records update and insert techniques. This was one of the interesting dilemmas in earlier Dexterity design. As you may know – SQL select or update statement deploys so-called aggregation and its performance is astonishing. However it is difficult to program SQL, which is compatible with multiple SQL vendors directly in C programming language. What is more natural to be created neutral to various DB platforms is cursor. Dexterity cursors are definitely very efficient, but when Microsoft acquired Great Plains Software in late 1990th, the question of being neutral to non-Microsoft DB vendors lost its actuality. The last version of Great Plains, where non-Microsoft database platforms were supported (Pervasive SQL 2000/Btrieve and Ctree) was version 7.5. Since the release of Microsoft Dynamics GP 8.0 release – this mid-market Corporate ERP application was only available on Microsoft SQL Server platform. Giving such excurse to the history, if you are coding in Dexterity – the recommendation is to create efficient SQL Stored Procedure and call it directly from Sanscript Dexterity code
3. Where to learn Dexterity. If you would like to dedicate yourself to Dexterity programming the best way is to find the job with one of the major Dynamics GP technology partner, especially the one, who is in Dynamics GP Source Code program. If you would like to learn it on your own – the learning curve might be too long and your earlier programmed products might be not perfect. Some notes, Dex is not technical Object Oriented Programming compliant, it is rather legacy procedural programming language. There were some attempts to make Dexterity object look like OOP ones in Great Plains Purchase Order Processing module, where in our opinion the code, due to that, is more complex and not friendly to Dexterity developer with long experience and proven expertise. So, if you dream about programming something very elegant, Dexterity might be a bit disappointing. But its custom dictionaries are absolutely integrated and user interface have the same look and feel, as native Dynamics GP forms, reports, menus, etc. Plus module coded in Dexterity automatically fits into GP security model
4. For additional information, please feel free to call us 1-866-304-3265 or 1-269-605-4904 (this number works for international customers) or email us help@alba866.com We serve you USA/Canada nationwide via remote support (web sessions and phone/Skype conferences). Local service is available in Western Michigan, Chicagoland, Southern California (LA, Orange County, San Diego), Houston area of the state of Texas
Dexterity Customization for Dynamics GP Evaluation Level Paper
When you are developer it is always a good idea to read technical manuals. But if you was just assigned to the IT team to decide if Dexterity is the right tool to customize your ERP application then first you need something which is in style of ‘easy reading papers’ or FAQ
Planning Dynamics GP Customization in Large Corporation
If you are reading this page then chances are high that you were not able to find ISV add-on and need customization project. Let’s talk about planning, quality assurance and future event such as version updates.
Dynamics GP Invoice Logo Attributed to Specific Company or Crossing the Borders of Three SOP Forms
Initial Great Plains Dynamics architecture had three SOP Invoice forms: Long, Short and Blank. Modern GP is popular in scenarios where you have more than three companies under one business entity umbrella
