Microsoft Business Solutions Great Plains, former Great Plains Software Dynamics and eEnterprise was designed in earlier 1990th as ERP, which can be easily transferable to the winning Database and OS platform and it was originally available on Mac and PC Mac OS and Microsoft Windows respectively. Graphical platforms battle is pretty much over and now with eCommerce demands, we should look at Great Plains Dynamics tables structure:
eCommerce development for Microsoft Great Plains: tools and highlights for programmer
The Internet has emerged as a cost-effective and reliable medium for performing online business transactions. More and more companies are now adopting this medium for procuring their goods. E-procurement advantages primarily include saving money, time, and extra workload normally associated with paper works. The conventional procurement process usually involves lots of paper processing, which consumes a large amount of time and money. In some instances, the processing cost has been reduced by as much as 85%.
Naming Convention. Great Plains was designed to be ready to move to the winning database platform and probably this is why we see this a bit complicated naming convention in place: SOP10100, RM00101, IV00101 these are samples: SOP header, Customer master, Inventory master. First we see module prefix: SOP Sales Order Processing, RM Receivables management, IV Inventory control, etc., then 0 stays for the master files, 1 so-called work files (before transaction being posted), 2 open files (after transaction is posted) and 3 historical files (when you close the year in General Ledger transactions are moved from open to history files). So as you see logic is present and structured, but it is not friendly to the developer, who never seen and worked with Great Plains Dynamics.
Tables Groups. Great plains was designed to first serve mid-size businesses and then with the availability of third party modules the intention was to compete on corporate ERP market with Oracle, PeopleSoft, SAP and others big players. This is why we see the whole cluster of tables to store, say Sales Invoice: SOP Header, SOP Lines, SOP Distribution, RM Key file, etc.
From the Forms side (or screens) you can see more human-readable names: SOP Entry, RM_Customer_Maintenance, POP_Entry or the like. But these legacy Great Plains Dexterity names do not help eCommerce developer only probably as the reference on which table works with specific screen.
Let s take a look at the tools available:
eCommerce together with eOrder, and other eXXX products it should be considered as legacy and phase out product, based on Microsoft eCommerce server and ASP technology, today Microsoft has new paradigm - .Net and ASPX World
eConnect was specially created for eCommerce developers, who integrate Microsoft Great Plains with eCommerce web interface. This tool covers a lot of Great Plains objects creation and retrieving functionality, however it does have restrictions, because it was not intended as replacement to Great Plains Dexterity shell. For example if you create Orders in SOP via Web interface/eConnect it is difficult manipulate these orders (transfers to Invoices, backorders, reallocations, etc.). Another issue with eConnect developers are kind of used to the fact that Microsoft provides free SDK to its products, Microsoft CRM for example has freely downloadable Microsoft CRM SDK. For eConnect you have to pay license and be on Microsoft Business Solutions annual support to get version upgrades. Also if you are ISV and develop your GP integration to your customers you have licensing issue with Microsoft.
Custom SOP/AR stored procedures. Microsoft Business Solutions partners in their practice usually have several Great Plains integration projects implemented where integration is realized on the stored procedures level and transactions are created and manipulated in Great Plains SOP. So you may end up seeking this type of help