1. SQL Aggregation as performance boost. In Dexterity we see Dex native cursors, these constructions allow you to abstract Dexterity sanscript code from low level DB query, but we know that cursors are similar to for statement in procedural programming languages (C, C++, C#, VB, Fortran, etc.). When the fate of GP database was determined, and Microsoft SQL Server was chosen to be the platform for the future, Dexterity programmers were encouraged to use select statement and call SQL stored procedures from Dexterity code. You can argue, that this option was available in the past, however if you think about GP ISV partners, they had to balance SQL and non-SQL Server platforms, such as Pervasive SQL and Ctree and supporting multiple platforms were easier in native Dexterity cursors. If you are Dexterity developer and you work for the company, deploying Great Plains as ERP, please feel free to review your Dex modifications and switch Dex cursors to SQL stored procedures

2. eConnect horizons. eConnect was specially designed for e-commerce application developers, allowing them to create, delete and modify GP master records and work transactions. Initially these options were only available to Dexterity programmer, and with eConnect MS Visual Studio.Net developers got some control over GP logic. If you have legacy Dexterity custom dictionary, please think about eConnect first as an option to upgrade your custom logic and port it into eConnect application. Dex has advantages of being seamlessly integrated with GP user interface and security model, however eConnect enables web applications to have some GP business logic

3. COM Objects and Web Services. In 1990th Dynamics had just a few compromises from OS independence principle – VBA would be one of theses. With acquisition by Microsoft, Dexterity gained new MS and Windows features: COM objects support, for example (Great Plains Dexterity 7.0 and later versions)

1. Integration Manager.  We understand that most of Great Plains Technical Consultants know how to setup simple integration, where the source are text tab or comma delimited files, including building document header by grouping text lines (by document date for example: General Ledger Transaction, Sales Order Processing Invoice, etc.).  However, we saw pretty tough situations, where Dynamics GP integration consultants had hard time in complex data conversions, where transactions and master records are in SQL tables or ODBC compliant databases: Oracle, MS Access, Pervasive SQL/Btrieve, Ctree, MySQL, or when they are exported into very complex text files (where you have to weed out formatting lines, as reports are exported in human readable format, which is not something that text integration accepts without data massage).  Good advice in our opinion in such scenarios is to import these text files into MS Excel, weed out formatting lines and then import the data into staging MS SQL Server tables.  Then you create SQL View to pull data from staging tables and use it as a base for Advanced ODBC Data Source.  We had cases, where we were able to import up to the whole year of mid-size company GL transactions via that method.  We would like also to share IM ongoing and close to real time integration methodic via Integration Manager.  If you have in-house programmed ecommerce website application, which requires close to real time or batch mode integration to Sales Order Processing (customer orders, invoices and returns) and new customers creation (where transactions are coming from Linux/PHP/MySQL based ecommerce application) – consider either exporting transactions in text file or even establishing ODBC connection from Dynamics GP hosting MS SQL Server to MySQL via Linked Server mechanism, and schedule IM Integration to run every 20 min or few hours via Windows Macro third party add-ons.  We know that for some of you these complex technical passages might be too deep, but our mission here is to let you (as struggling ecommerce programmer) know what is possible with Dynamics GP ecommerce integration.  And finally, the last observation, before we move on to eConnect technology, please know that IM for GP version 10.0 is available in two connection blends – traditional OLE Server and eConnect connectors.  eConnect connectors are faster by their technology architecture and technically you may be achieving the same results as if you are programming eConnect directly from your ecommerce web application, where the advantage of Integration Manager is apparent – it is user friendly in integration design and doesn’t require programming (except simple VBA scripts, or data translation tables, which could be composed in MS Excel)

2. eConnect Integration Programming.  eConnect was introduced for Dynamics GP version 7.5 and 8.0 as the Software Development Kit, initially dedicated to eCommerce software developers.  eConnect was under certain evolution for Dynamics GP versions 9.0 and 10.0, where it was adopted as integration technical platform strategy (and it was announced by Microsoft Business Solutions that eConnect should replace earlier integration platforms: Integration Manager, Dexterity – as middle tier).  And now as we are writing these lines (October 2009), eConnect is triumphing among Dynamics GP integration low level technologies and connectors.  eConnect technology is in fact simple – it is the collection of SQL Server encrypted stored procedures, replicating Great Plains Dexterity Dynamics GP business logic (often in Object Oriented Programming style, and this is good improvement to Dex, which is not technically Object Oriented Programming compliant with some exceptions).  In our opinion eConnect came to its maturity as reliable Dynamics GP ecommerce and generic integration Software Development Kit with Great Plains Dynamics GP version 10.0 and probably 9.0.  If you got certifications and experience as Microsoft  .Net VB or C# programmer, you should find very useful code samples and prototype Microsoft Visual Studio eConnect projects: Dynamics GP Sales Order import, Customer import and update (including addresses) to give you start up ideas

3. Dexterity integrations.  Dex is capable to do the ultimate and the most complex programming surgery in Dynamics GP system environment.  If Integration Manager and even eConnect don’t do the job or incapable to do the job (and this is possible as these tools have natural limitations).  However, please recognize the challenges of Dexterity.   In Dynamics GP realm there are no limits to Microsoft Dexterity customizations, and if you contact with Great Plains Dexterity programmers (who have access to Dexterity Source Code and have experience in Dex source code programming), please go ahead to evaluate these channels.  The only advise we would like to feature here is fact that Dexterity requires too long learning curve for newcomers, and it is not recommended for small or mid-size companies IT department to do Dexterity custom programming inhouse

4. Direct SQL Data Feeding.  If you are experienced Microsoft SQL DBA, please review Dynamics GP Tables Structure Tools->Resource Description->Tables (or install Dynamics GP SDK from DC#2, where tables structure is formally documented).  We would like to make comments and recommendations, before you try direct SQL data feed via SQL Stored Procedures.  Please, consider the fact that eConnect is already doing this job via its methods and Stored Procedures.  Also take into consideration the fact that Dynamics GP business logic and data flow is quite complex and it is unlikely that you can do imitate this logic in couple of day, couple of week or even in couple of months.  If you have unlimited IT budget, then please disregard and go all the way through until you consider yourself experienced eConnect programmer with comfort to send records directly to Dynamics GP tables: GL10000, GL10001, SOP10100, SOP10200, SOP30200, SOP30300,etc.

5. Great Plains Integration options for Old GP versions: 8.0, 7.5, 7.0, 6.0, 5.5, 5.0, 4.0 and Great Plains Dynamics on Pervasive SQL Server 2000/Btrieve and Ctree.  If you are on archaic version, it is unlikely that you can get support directly from Microsoft Business Solutions Dynamics GP subdivision (as you are likely not current in MBS annual enhancement program)

6. Great Plains Accounting for DOS, Windows or Mac integration options.  GPA has its own integration module, and if this is your Corporate ERP, please contact us separately,  we have access to GPA knowledge base, inherited from Great Plains Software – if your case is known and documented (plus if you can recognize your problem in GPA after 10+ years of GPA and Dynamics GP Consulting), we are uniquely positioned to support Great Plains Accounting for DOS, Windows and Mac: 9.5, 9.2, 9.1 or earlier versions USA and Canada nationwide and internationally most likely Central, South America, Mexico, Caribbean, Pacific, Malaysia, Indonesia, Singapore, Saudi Arabia, Kuwait, Pakistan, Casablanca, Agadir,  India, Bangladesh)

7. Unicode characters integ
ration notes.  Great Plains Dexterity doesn’t support hieroglyphs: Chinese, Japanese, Korean, Mongolian, Thai.  All we can do for you is enable hieroglyphs in Crystal Reports or Microsoft SQL Server Reporting Services (often abbreviated as SSRS)

8. Dynamics GP Great Plains in Russian Federation, Kazakhstan, Uzbekistan, Azerbaijan, Poland, Czech republic, Latvia, Estonia, Lithuania, Romania, Slovakia, Georgia, Armenia.  Great Plains Software tried to market and localize Great Plains (version 4.0 and 5.0) in Common Wealth of Independent States (most of the former Soviet Union territory, except East Baltic States) .  When Great Plains Software was in its order acquired by Microsoft Business Solutions, MS recommended Navision as the Corporate ERP of choice back in earlier 2000th, and later on MBS localized Axapta Microsoft Dynamics AX for most of Western, Central and Eastern European Corporate ERP markets.  To avoid further complexities, we recommend you to chose SAP Business One in former CIS, Baltic States and in Arabic World as good local branch Corporate ERP, which has simple integration tools and options to your Dynamics GP ERP in the headquarters

9. How to get help?  Please, feel free to call us: 1-866-528-0577, outside of USA: 1-630-961-5918 or email us help@albaspectrum.com  We are very technical and real Dynamics GP Dexterity, SAP Business One SDK and Microsoft CRM programming gurus.  We have Great Plains Software Development Factory and could support unlimited Dynamics GP Customization and Programming needs.  Plus we speak English, Chinese, Spanish, Portuguese, Arabic, Russian, and not only as native speaking sales folks, but as real technical consultants.  If you prefer skype: albaspectrum

get sharing files over the internet

1. eConnect. This is Software Development Kit with sample codes in VB and C#.Net. At the end of the chain eConnect calls encrypted SQL stored procedures, which you can not modify, and you shouldn’t as these procs replicate Dexterity business logic, where eConnect has some features of Object Oriented Programming. eConnect was initially dedicated to eCommerce Microsoft Visual Studio developer, who is given the objective to integrate e-commerce website with GP ERP at the back end. eConnect has some restrictions, one of them is lack of batch posting ability, so we recommend you Alba Spectrum Posting Server

2. Auto Posting Server. Again, GP is written in Microsoft Dexterity and it has its internal logic, which is available for Dexterity source code developer. Posting Server calls GP Dex batch posting native logic to post batches in the queue. You, as SQL programmer should place batches, created in eConnect or Integration Manager into this queue table. In our opinion, this product is more flexible and gives you more control, than Autopost, developed by Parity Software, GP VAR from South Africa

3. Modifier with VBA. If you have comfort level in VBA scripting and past experience programming and modifying MS Excel, Access, Word or other office applications with VBA, the research this option of GP customizing. Modifier allows you to place new fields to GP forms and screens and then you as programmer can associate VBA scripts with these new fields. If you plan to alter DB, by clicking or filling up new fields, please be sure that you are familiar with Microsoft ADO technology

1. Programming in Dexterity. Dex is not technically Object Oriented language, so it is really hard to program Dex by example, as you would expect in the case of C# or VB.Net. Plus Dexterity is associated with Microsoft Great Plains architecture, this is why programming Dexterity requires several years of GP technical support experience, including GP data fixing with SQL scripts, data conversion, where you feed data from legacy MRP system to GP tables. You should also be familiar with major GP screens: SOP entry, GL transaction, POP Purchase Order, Inventory item maintenance.

2. DYNAMICS.DIC. This is Dexterity built dictionary, please be assured, that Dexterity source code is stripped out and as a programmer you will not find there procedures and functions scripts. In order to analyze Dex power and functionality, please review Dexterity manuals, available on Microsoft Dynamics GP 10.0 CDs

3. Custom and Alternate Dynamics forms. Dexterity architecture allows you to build new forms, as well as modify existing ones. Alternate forms are typically the issue in GP version upgrade, so we recommend you to avoid existing form modification option. Instead you should consider Dex triggers to work with existing forms and modify logic with the trigger

4. Extender. eOne version of extender allows you to deploy Dex power not being Dexterity developers, however you should expect limitations