Article Surfing Archive

Microsoft Great Plains customization specking out might be challenging enough, especially if you try to think about GP modification from the perspective of .Net *surface* mods, not getting to the Dexterity depth * its tables structure, records workflow (how transactions are distributed in SQL Dex tables clusters: master, work, open, historical). As GP consultant you naturally understand that if you spec out customization, you need to decide on programming tools, and this in turn determines the customization architecture. Currently GP modification, reporting and integration tools are .Net, Dexterity, SQL scripting, eConnect, Integration Manager, Modifier with VBA, Extender, ReportWriter, SRS, Crystal Reports; in the case of Business Portal customization is more challenging, it is in .Net and UML and you do not have the option of direct modification access to SQL server. Let's come through the techniques and options:

1. Business Logic mapping. This part is the most important. You need to decide how your customization extension will integrate with existing business logic. It might be independent custom logic with following integration to GP tables * in this case you should be familiar with GP master and transactions records distribution in GP. The easiest and most reliable approach is to imitate intended integration records via Great Plains user workstation data entry

2. .Net. Consider web ecommerce data publishing from Great Plains SQL tables. However, make your homework and research GP tables structure. Open GP workstation and go to tools->resource description->tables. We only intend here to orient you for the next step, not really give you complete solution, so you is the one to explore the further options

3. eConnect. In addition to above option, eConnect will give you some comfort level manipulating master and work transaction records in GP. In eConnect you can not post Great Plains transactions, due to Microsoft Great Plains Dexterity architecture * posting is left to GP users

4. Modifier/VBA. This tandem was very popular in 1990th and earlier 2000th, however now it is legacy as it is not .Net compliant. VBA is also Integration Manager modification tool. VBA scripting is very powerful * you can include Dexterity sanscript scriplets into Modified forms logic, which is very cool, but unfortunately not easily upgradeable to new GP version. VBA usesOLE Server functionality

5. Microsoft Dexterity. Former name is Great Plains Dexterity. This tool requires professional Dex developer, otherwise you will get into years long learning curve with all the known development errors and traps. The beginning of Dex learning are Dynamics.dic, Dex.ini, Dynamics.set, DEX_ROW_ID

6. Integration Manager. Besides obvious and intuitive integration you can extend it with VBA scripting and data translation. At this time IM is in process of being redesigned in eConnect (on the business objects level * SQL stored procedures), this should resolve known IM performance issue. Consider direct eConnect programming if you plan to integrate over ten thousand records per day

7. Reporting Tools. You should be aware that both SRS (SQL Server Reporting Services) and Crystal Reports will more likely require SQL Stored Procedures or SQL Views to be based on. If you decide to follow the *wizard* approach * the chances are high that you will end up with long term debugging and then move back to SQL stored procedure or view

8. ReportWriter is Dexterity module with all the pluses and minuses of this legacy technology. Report Writer reports version update is known as challenging, especially if you are not happy to redesign several reports from scratch. Known trick is as this * open new (non modified) and old (modified) version of your report and compare calculated fields