Microsoft Dynamics GP add-ons are often written in Great Plains Dexterity – with new and sometimes alternative GP forms and windows where the buttons, have scripts and forms themselves have procedures and functions.
These programming parts are written in Dex Sanscript programming language. Sanscript is sort of proprietary scripting language, typically you can get Dex programmer from GP ISV and customization partners, you should check with your Great Plains VAR for details. When newer Dynamics GP version is released, if you plan to update to it, you have to take into consideration Dex modification upgrade requirement. In this small publication w would like to orient you what you could expect from technical side:
1. Alternative GP Forms. These objects typically require special attention, and let us explain why. Imagine, you have customized GP Sales Order Processing Entry form for GP say version 8.0. Now, you plan to upgrade your customization to version 10.0. In version 10.0 GP has (potentially) redesigned some functionality, added and took off several fields and buttons. Your modification for 8.0 might of be dealing with the functionality, changed or even not present with version 10.0. This is why Alternative GP forms are the ones, where Dexterity programmers spends large portion of upgrading code revision
2. New GP Forms. This is when in your Dex add-on you create the form from scratch. New forms are typically less sensitive to the version and in majority of the cases should work fine, if you simply reapply Dex chunk with your add-on to the new version GP workstation
3. Calling GP Stored Procedures from Dexterity code. If you have your own custom stored procedure, which you call from Dex code, you need to review its SQL script – typically check if new version of GP has any changes in the tables, addressed in the SP. If you call GP original stored procedure, then, you should review GP SDK to see if new version has the same set of parameters
4. Performance improvement considerations. If you are upgrading from really old version, especially when you move from old DB platform, such as Ctree or Pervasive SQL to MS SQL Server, then you can consider offloading some of the Dex logic, usually found in Dex cursors to custom SQL Stored Procedures, where you can benefit on the aggregation performance: Select or Insert in SQL would work a way faster than Dexterity cursor
5. Exotic Sanscript programming examples. In late 1990th we saw such techniques in Dex software development as inserting scripts into VBA code. This technique allowed you in one custom add-on to address several GP dictionaries – popular example is GP Vendor Invoice and Intellisol Advanced Purchase Order Processing. If you have something like that – we advise you to redesign it, as it is virtually impossible to debug such code samples
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
