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. ERP annual maintenance plan. Nowadays software industry deploys this practice, when your purchase of MRP system just opens the door to ERP implementation, following support, access to newest versions, etc. Naturally, all these benefits have a cost for software development company and they are typically translated to you in the form of ERP annual enhancement program. Check with your ERP partner that you are current in this plan

2. Cross-platform integrations upgrade. In our opinion, ERP customers spend extra funds in cross platform scenarios, such as when their Sales Order Processing system is hosted in Linux/PHP environment and ERP application is Microsoft SQL Server and Windows based, here you should also recognize that MRP upgrade process requires IT person or programmer, who is comfortable with both platform: UNIX and Microsoft Windows in our example

3. Microsoft Dynamics GP upgrade scenarios. GP customizations, especially legacy ones were typically done in Great Plains Dexterity IDE and sanscript programming language. Reporting tools: FRx, Microsoft SQL Server Reporting Services or SRS, GP ReportWriter (where you modify such popular reports as SOP Blank Invoice Form) and Crystal Reports; eConnect opens the door to Microsoft Visual Studio .Net C# or VB developer to the realm of GP objects: customers, vendors, employees, GL transactions, Sales and Vendor Invoices

4. ERP rollback rescue. Obviously, we are optimists, however we should consider contingency plans, where we roll back to old positions. In the case of corporate ERP version update, rollback may cause substantial business opportunity loss

5. Switching from one ERP to another. When you have been operating on ERP A, it is not easy to switch to ERP B as it typically triggers fullscale data conversion and migration, employee retraining, custom logic reprogramming

1. GP Integration Manager. IM is intuitive integrating tool, which allows end user to design query, map query fields to GP business objects, such as GL account, SOP Invoice and all the other (except probably some exotic ones, typically related to newly acquired modules, very new functionality, or the like). If you need to alter standard GP integration logic, IM allows you to deploy VBA scripting and program events: before query, before document and others. To give you practical example – in before document event VBA script could alter document date, if you would like to issue your integrated invoices twice a month, while integrating every day. Besides VBA scripting you can deploy field value translation – if your integration query gives you customer ID as 100 and in GP it is AARONFIT001, you can import translation table and apply it in your integration. Translation table can be imported in Excel format

2. eConnect. This tool opens integration door to MS Visual Studio .Net C# or VB programmers and among them are eCommerce developers. eConnect core is set of encrypted SQL stored procedures, which replicate GP Dexterity business logic – this means that eConnect “validates” GP logic and it is a way safer than direct SQL scripting. eConnect covers the majority of GP modules and objects, however it doesn’t cover such modules as Invoicing (however it covers Sales Order Processing or SOP module, which is more powerful one)

3. Microsoft Dexterity, former name is Great Plains Dexterity. This IDE and programming language allows you to go into GP heart and utilize its source codes and engines. The example of Dex customization is Albaspectrum Posting Server, which allows eCommerce eConnect developer to post Sales batches directly from eCommerce application, which is not possible in pure eConnect. Dexterity allows you to create all the thinkable integrations, however it requires Dex programming experience and it is not recommended to count on newcomers in Dex.

4. SQL Scripting. If eConnect is not an option for you (where we would strongly recommend you to review eConnect one more time and change possible your mind in favor of eConnect option), you can go ahead with SQL scripts. Review GP table structure in Tools->Resource Description->Tables, then in GP test environment create the transactions you plan to integrate via GP user interface and analyze the records created in the tables. Try to feed one transaction in test company and then try to run check links: Maintenance->Check Links, select your series and work or master tables in them – be sure check links doesn’t produce error report. SQL stored procedures integration is not self evident and here we just give you initial orientation.

1. Sales Order Processing and Vendor Drop Shipping. If you have strong presence on the web as eCommerce reseller, there is the chance, that what you actually do is transfer customer sales orders to vendor drop ship purchase orders. If this is the case, you will need to integrate your SOP system with Microsoft Great Plains. The first and the most reliable tool to choose from and consider on the first place is GP Integration Manager. In IM itself, please review eConnect connectors to integrate Sales Order Processing and Purchase Receipt documents. eConnect route is definitely faster, in order to see the difference you should know that traditional IM connector uses Great Plains workstation as OLE server to do the job, basically filling up fields in the form and so, validating business logic

2. Direct eConnect programming. This option should be faster in comparison to Integration Manager way, as IM eConnect connector has to do all the steps in business logic validation, while in eConnect MS Visual Studio.Net c# or VB programming you can choose the steps to perform in business logic validation. However eConnect “atomic” stored procedures might still be less efficient as they had to validate the logic of Microsoft Dexterity

3. SQL Stored Procedures approach. SQL is definitely the fastest tool to try, however you should be proficient in SQL scripting and understand the impact of various SQL expressions on GP data extraction and manipulation performance: Select versus SQL cursor is good example. This is not the only warning – when you use SQL update, delete or insert query, you can damage GP DYNAMICS or company database tables

4. Integration Mapping. Your employees or traditional IT department contractors might be giving you the signal that they’ll integrate Microsoft Dynamics GP with your legacy Sales system. Microsoft as successor of Great Plains Software, knows that GP is mid-size ERP package and being such it requires consulting partner network to sell MRP software and do certified GP ERP installation and implementation. Of course your people could ultimately and theoretically be done with the GP implementing job, however you should understand the risks and learning curve cost impacts

5. Diving to Technology Ocean. GP technologies include: Microsoft Dexterity, SQL Server 2005 and 2000, GP ReportWriter, GP Modifier with VBA, Crystal Reports, eConnect and XML Web Services, GP Integration Manager with eConnect connectors. MS Sharepoint and GP Business Portal at this time are in market attacking mode, so if you need such practical modules as Electronic Document Delivery, Requisition Management (successor of eRequisition), Order Management (successor of eOrder)

6. Pervasive SQL or Ctree integrations. There are chances that your company had hard time in earlier 2000 and you lapsed to pay Microsoft Great Plains annual enhancement program. In this situation, if you plan to get new GP version, currently GP 10.0 license keys, you will have to undergo GP enhancement reenrollment procedure

1. EDI. It is often considered by software developers as something very complex, where UNIX world is interchanging vendor records, vendor invoices and purchase orders to replenish company inventory or fulfill the order. However if you look at EDI realization, you will often realize that it is simply fixed width text file or combination of fixed width text fields with encrypted numeric fields, where numeric fields you can process and convert into text with relatively simple character processing programming. If you came to the point where on the input side you have fixed width text fields, what you need to do now is to create SQL insert into script and send records into GP tables. The second option is to get formatted fields via select statement and call eConnect methods to send Vendor Invoice into GP for example. In order to parse fixed width text fields in SQL select statement you should read books online and get answer there.

2. Dexterity and eConnect. GP users like Dexterity customizations, as these customizations are seamlessly integrated into GP user interface and security realm. However GP user interface assumes that you as GP user is logged into specific GP company and do your work in this company: enter invoices, post batches, etc. When you are designing customization with eConnect and Dexterity there is simple opportunity to break through single company. Dexterity allows you to call com objects or dll libraries, in turn com object could be written in .Net C# or VB, where you use ADO.Net constructions to switch SQL Server databases, staying for GP companies. As eConnect interface call is stored procedure, this is simple for programmer to call stored procedure in any database he or she likes. Considering legacy technologies, such as VBA scripting with Dex sanscript codes in and Continuum techniques – extension to switch Great Plains Dynamics modules; switching GP companies was always really difficult to accomplish in your integration, so eConnect, Dexterity and DLL combination seems to be very promising

3. GP and Java integrations. Reliable approach is to open eConnect interface via custom web services, which you can call from your EJB, J2EE, Java or Oracle application. Please note that GP is Microsoft realm and if you deploy non-Microsoft technologies such as DB2, PHP websites typically require technology integration testing

1. MS Great Plains platform overview. GP workstation is written in C Shell, named Great Plains Dexterity. It was designed in earlier 1990th, when DB and OS platform independence was the paradigm. However, when Microsoft acquired Great Plains Software seven years ago, Microsoft Dexterity was kind of de-emphasized and GP itself was open for .Net platform and for Microsoft Visual Studio C# and VB developers, especially via eConnect. Plus, GP is available on Microsoft SQL Server DB platform only. Saying these, Microsoft Great Plains version 10.0 and 9.0 should be considered as committed to Microsoft technologies: SQL Server, .Net, Windows, MS Office: Sharepoint, Excel, etc.

2. Cross Platform SQL Queries. If you do it from Microsoft SQL Server 2005 or 2000 side, the construction you typically use is Linked Server, where you should first try ODBC connection to Linux World. If you are on Oracle, then similar construction will allow you to hook up MS SQL Server

3. Web Services. eConnect allows you to open GP objects for non-Microsoft developer via XML web services – you can either use eConnect interface directly or wrap it in custom web service interface

4. eConnect excurse. The core of eConnect is set of MS SQL Server encrypted stored procedures, allowing you manipulate GP master records and work transactions: SOP Entry, POP Receivings, Customers, Vendors to name a few. eConnect has restrictions of GP architecture, one of the typical FAQ is why we can not post GP batches in eConnect? Well, this is the restriction, but you can break it utilizing Albaspectrum posting server. eConnect was dedicated initially to eCommerce software developers, to enable GP ERP platform as backoffice accounting for e-commerce front end

5. Integration technology. Here again eConnect comes to the scenes. GP Integration Manager, which is rather traditional Great Plains integration tool, was recently redesigned partially in eConnect and so IM performance was substantially increased. IM can read tab and comma delimited text files as well as ODBC compliant queries. When you are programming integration, be sure that you select eConnect destination connector as preferred, versus deploying regular destination connector (old-fashioned connectors use GP workstation as OLE Server to validate Great Plains business logic directly in GP screens, which obviously slows down the performance)