Microsoft Great Plains Software development: typical scenarios in Sales Order Processing module

Jan 15
09:22

2008

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

Microsoft Dynamics GP has a set of SDK and programming tools to enable business logic customization for software developers. You can utilize Extender, VBA with Modifier, direct SQL scripting as well as eConnect object calls from Microsoft Visual Studio C# or VB projects

mediaimage

However if the modification should be seamlessly integrated in Great Plains user interface,Microsoft Great Plains Software development: typical scenarios in Sales Order Processing module Articles you should consider Microsoft Dexterity tool.  Regardless of the tool, you need to understand which GP objects should be modified and where to find their description:

1.    Great Plains Tables description.  You can install Microsoft Dynamics GP SDK or Software Development Kit, which has comprehensive overview of GP tables and their relations.  If you work closely with GP users, you can get tables snapshot in GP interface: Microsoft Dynamics GP->Tools->Resource Description->Tables.

2.    SOP tables, often participating in modification.  GP design distinguishes work, posted and historical tables.  In the case of Sales Order Processing module you see Sales Work Documents: SOP10100 – Sales header and SOP10200 – Sales lines tables (to name key tables, there are other tables as well, outside of the scope of this article); and historical tables: SOP30200 – Sales header and SOP30300 – Sales lines

3.    Modification technique.  You actually never change original GP tables; instead you add your new custom tables and link them one-to-one with GP original tables.  In the case of Sales header table, you link your custom table by these two fields: SOPTYPE and SOPNUMBE – Sales document type and Sales number respectively

4.    Typical modifications in business logic.  Imagine – you have return and you would like to associate it with invoice.  Custom logic may have custom screen, where you select invoice number and click Create Return button.  The logic copies all the items and qty from chosen invoice and creates reversing return.  This is one of the typical scenarios, where your business has special automation requirements, not available in GP or any other generic ERP application.  The example above is very good candidate to be considered and implemented in Great Plains Dexterity

5.    Additional Considerations.  As we are talking about mid-size MRP application, where Great Plains Dynamics GP belongs, altered business logic is not a five minutes change.  GP objects model is relatively complex, plus if you decide on Dexterity programming – it requires several years of extensive software development to get enough under your belt to consider learning curve to be finally behind.  In any case – do not hope on short cuts or easy ways to get by