Microsoft Great Plains is currently undergoing a substantial technology redesign. To remind you of history, Great Plains Dexterity was designed in the early 1990’s as an IDE and shell, written in the C programming language to become a scripting and development tool – Sanscript language. Later, Microsoft bought Great Plains Software at the brink of the 21st century. At about this time, we see two products emerging: eXtender, written by the Australian company eOne, and eConnect, a tool initially designed for web e-commerce developers. The question of choosing the right tool for the development of your specific GP software usually requires additional research, so in this small article we will try to guide you, assuming that you are a programmer and consultant, and that you have some exposure to the architecture of the corporate ERP system. and accounting.
or Dexterity. The idea was brilliant in the early 1990s to provide Great Plains Dynamics with some level of computer platform and database independence and quick turnaround in an emergency. The C programming language was introduced for most platforms from the old days: Unix, IBM PC/Microsoft Windows, Solaris, AIX, later on Linux. As an expense of this flexibility, Dexterity had to use a cursor-driven data access/modification engine, to compare with SQL SELEC and UPDATE statements added. Aggregate statements provide much more advanced performance
or extender. Sometimes you think of funny questions in software development. Let’s say we provide a shell on top of Dex and train the end user or developer to prototype new custom logic in forms, tables, views and even provide the mechanism to include dex sanscript scriptlets. Would that be an advantage over using Raw Dexterity to build this whole thing from scratch? The answer is most likely: yes, this is great and it is much easier and more reliable to implement a secondary shell (extender), however you need to understand the drawbacks. Extend, being the dex build, should probably share the future fate of dex technology. And second, if you’re producing custom plugins for Dynamics GP, you should probably use the starter tool. However, if you are an end customer and just need to get a job done, Extender is a good option.
or eConnect. This tool resolves the limitation of Dex as a proprietary scripting language and opens up the GP object pool for Microsoft Visual Studio developers. Also, eConnect has an object-oriented approach, which means it’s much easier to program as a “modern programmer” – it eliminates the need for a lot of QA traceback testing, assuming you, as a software coder, follow object-oriented rules with precision. You can use the language of your choice or the philosophy of your choice: C# (former Java developers) or VB.Net – former VB programmers, as well as the full spectrum of X.Net languages
o Combining Dexterity and eConnect. In our opinion, this is the most recommended form of GP mods for the next 5-10 years. Dexterity Forms integrates it into the “big” client security environment of Microsoft Dynamics GP and can be opened intuitively from the GP workstation. It then passes the business logic to the custom logic developed by Visual Studio, calling eConnect through the XML web service interface
or Reports. We see three tools here: MS SQL Server Reporting Services, GP Report Writer (legacy dex tool), and Crystal Reports. You should probably consider the MS trends here first: SRS (pretty much ditching the old Crystal Reports orientation). The good news is that SRS is intuitively understood to be part of the Crystal Reports designer, so fear not, install SRS and port your reports to a new platform. Regarding the ReportWriter, if you have custom SOP Invoice Long Form or Field Services, you should probably keep updating these custom reports in the ReportWriter. Report Writer is integrated with the GP workstation and does not require additional modules to do the job of calling reports
o Proficiency source code programming. MBS has source code programming partners, who in turn have a Dexterity programmer, familiar with low level sanscript source code (contained in DYNAMICS.DIC with code, regular distribution removes sanscript code from this dictionary)