Planning Dynamics GP Customization in Large Corporation

This paper is not technical and rather addressed to managerial team.  If you are developer we recommend you to read our technical paper published earlier.  Let’s begin with tools quick review:

1. Tools.  The architecture is based on Microsoft Dexterity formerly known as GPS Dexterity.  You Dex dictionary will be integrated with the application and listed in Dynamics.set file.  Here you have similar user interface and it is in security realm.  If you plan to integrate external application and send data to GP then you may be think about eConnect which creates, updates and deletes word documents (SOP Invoice, GL Entry, etc.) and master records (customer, employee, vendor, etc.).  You can modify existing forms in Modifier and animate them with event driven VBA scripts.  From generic programmer perspective only Dexterity here is ‘something unknown’ with proprietary programming language named ‘Sanscript’.  Let’s now concentrate on Dex customizing and project management

2. What could be recommended not to do?  Programmer might be flexible and offer you something that you would rather avoid.  For example if you need price altering based on customer historical order than instead of adding SOP Entry form into dictionary and altering logic on the form scripts better idea is to do it in so-called Trigger.  When form itself is customized then version upgrade will require code review and possibly ‘reapplying’.  Trigger is more ‘immune’ to versions and service packs

3. What should we include in the contract?  Probably important thing is to own ‘source code’.  If your project covers something that is important for your business processes then let’s think a little bit about its architecture.  Developer usually delivers the code in so-called ‘chunk’ file.  It is produced by exporting Dictionary into Extract.dic file with following transformation into ‘chunk’.  When chunk file is copied into client workstation folder next login will integrate the logic and final dictionary will be created.  However this dictionary doesn’t have source Sanscript codes as they are ‘stripped out’.  Let’s assume that today you have perfect confidence regarding your developer.  But in the future programmer may switch his employer or simple change profession.  If you do not have Extract.dic or Dynamics.dic which was used in programming then there is no way for somebody else to pick up the project and do modifications (as you do not have source code)

4. Let’s now think about preparing to programming.  There is no reason for coders to sit in your office all the time.  Better idea is remote access.  Think about opening test server with copy of your production company for coding and testing.  Think about the fact that your custom logic is unique and nobody else would help you with software bugs catching and fixing (which is normal if you are deploying ISV channel add-on where they have a lot of customers who might potentially report the bug and it is now fixed).  There is so-called ‘Lesson Company’ but custom logic is often specific data driven.  It means that in order to reduce QA budget have your programmer to test their code against your real data as test server companies are restored from production backup

5. What is we have data security concerns?  This question is important in large organization.  There is ‘Clear Data’ option and you may consider to clean most of the modules historical, open and work tables.  But of course you need to give developing team data sample which is related to modification

6. If we have offices in several countries and custom logic should be available in several languages what is the best approach?  We believe that simples and reliable way is to include custom dictionary into Modifier and translate String Resources there.  Then for each language you may have dedicated Citrix server with Forms.dic translated to their respected language

Let’s now answer several questions from the internet:

Q.  We are multinational corporation with headquarter in Chicago and locations in Argentina, Brazil and China and we use Great Plains here in the United States.  Is it possible for us to have all our international offices on GP?A.  The answer is probably not.  In Argentina you can definitely do that.  However in Brazil and China you will have issues as application is not translated (by Microsoft) into Brazilian Portuguese and Chinese.  Plus to our knowledge Brazilian SPED (Public Digital Bookkeeping System with XML electronic reporting) is not something that you would like to program in-house.  Dexterity doesn’t support Unicode meaning that Chinese hieroglyphs could not be enabled in Modifier.  There is NJ Star product which enables limited support in Chinese but we would rather be on the skeptical side

Q.  We have heard about Microsoft Visual Studio Tools.  Maybe instead of Dexterity we should use VST and do programming job internally?A.  This is one of the options.  There are nuances however as if you need new table to be introduced it should be described in dictionary and in order to do that you need Dexterity.  Maybe you should think that at this time there is no complete ‘independence’

For additional information please call us: 1-866-528-0577, 1-630-961-5918 or email us: help@albaspectrum.com