Microsoft Great Plains e-Commerce – additional considerations for programmer
 by: Andrew Karasev

Microsoft Great Plains, designed back in 1990th as database transferable and graphical platform independent ERP application – Great Plains Dynamics/Dynamics C/S+/eEnterprise. For eCommerce developer the most important is to understand Great Plains tables structure and business processes in Sales Order Processing, Accounts Receivables, Inventory Control (inventory items allocation, backordering, etc), posting to Bank Reconciliation and General Ledger. And this is where Great Plains structure seems to be not transparent. Let’s give you highlights:

1. Great Plains Tables Structure. Open Great Plains, if on version 7.5 or prior, Tools->Resource Description->Tables, then you should select Sales series, explore these tables:

2. Sales Order Processing module (SOP)

    * SOP10100 – Sales Order Processing header

    * SOP10200 – Sales Order Processing lines

    * SOP10102 – Sales Distribution Work and History – it is how Invoices will be distributed in GL – in case if you are creating quote or sales order with the following processing in GP backend – you do not need distribution

3. Accounts Receivable module:

    * RM00101 – Customer Master

    * RM00102 – Customer Address Master – each customer can have multiple addresses for delivering, billing, statement mailing, etc.

4. Possible issues and recommendations:

    * If using eConnect – you may decide to transfer Sales Orders to Invoices automatically with eConnect – this might be tricky and additional scripting might be needed, especially if you are doing automatic order allocation by line item. If you are trying to relay on eConnect exclusively and not researching Great Plains Architecture – you will need additions to eConnect from third party vendor, such as Alba Spectrum Technologies, which has the whole set of SOP populating stored procedures

    * If you are not using eConnect and creating your own custom stored procedures – you should probably create orders or other objects in Great Plains and then look at the way how they were recorded in SOP tables

    * If you feel that you need to relay on Great Plains engine behind the scenes (because you feel that imitation will require you to rewrite substantial portion of Great Plains logic) – you could deploy Dexterity triggers from Great Plains side – this solution requires professional Dexterity programmer and is more reliable and upgrade – proof

Good luck with implementation, customization and integration and if you have issues or concerns – we are here to help! If you want us to do the job - give us a call 866-528-0577 or 630-961-5918! [email protected]

About The Author

Andrew is Great Plains specialist in Alba Spectrum Technologies ( http://www.albaspectrum.com ) – Microsoft Great Plains, Navision, Microsoft CRM Partner, serving clients in California, Minnesota, Illinois, Washington, Florida, Arizona, New York, New Jersey, Virginia, Georgia, Louisiana, Texas, Canada, UK, Australia, Brazil, Germany, Russia

[email protected]