Microsoft Great Plains eCommerce – stored procedures approach
Since Version 8.0 Microsoft Business Solutions Great Plains & Great Plains Standard are available on Microsoft SQL Server and MSDE (which is in fact MS SQL with database size limit of 2GB). As eCommerce designer you should be aware of several options and customization tools in your disposition, when you utilize Microsoft Great Plains 8.5 (June 2005), 8.0, 7.5, Great Plains Dynamics/eEnterprise 7.0, 6.0, 5.5 or 5.0 Great Plains Dynamics C/S+. When you have old versions (7.5 and prior) we assume that you are on MS SQL Server 2000/7.0, because if you are on Ctree or Pervasive SQL/Btrieve – you should use ODBC / RDO connection tools, such as MS Access and its queries or use MS SQL Server Linked Server technique with OPENROWSET statements. So, lets assume that you are on MS SQL Server. You have basically two options eConnect (you should pay for the reg key/license and this is SDK) and custom stored procedures. We’ll only consider custom stored procedures way here:
- Stored Procs. The first question is – are we allowed to create stored proc in Great Plains DYNAMICS and companies databases. The answer is Yes – opposite to such products as Microsoft CRM (where you are banned to create any custom object in MS CRM database, and instead you create your own custom database and place all your procedures and views there) – you are encouraged to create your stored procedures and place them in both DYNAMICS and Company databases. You need to know the anatomy of Great Plains tables structure
- Tables Structure. If you launch Great Plains workstation and follow this way: Tools->Resource Descriptions->Tables – then you are in tables descriptor, sorting by tables Physical, Logical or Tables Group Technical names. This is all Great Plains Dexterity architecture realm and it is relatively complex and not
Ecommerce - Google News
“developer-friendly” – but if you create sample transactions in Great Plains – you can figure out where data should be populated
- Sales Order Processing. Or SOP module. This is usually the core of eCommerce development – transactions should go into SOP tables (with SOP prefix): SOP10100, SOP10200 and others. If you are selling to your existing customers, then customers are in Receivables Management module (AR) with AR prefixes: RM00101 – is Customer Master, RM00102 – customer address master, etc.
- Sales Order/Invoice Allocation dilemma. Great Plains SOP module is working in concert with Inventory control, making allocation of inventoried items in IV. So, this is very challenging to replicate allocation logic. We recommend do not allocate in Orders and Invoices and do allocation by operator, who processes the internet orders batch
- Sales Order transfer dilemma. If you are using eConnect – this is kind of issue, so you have to appeal to GP internal architecture and do it with the stored procs approach.
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 1-630-961-5918 or 1-866-528-0577! help@albaspectrum.com
About The Author
Andrew is Great Plains specialist in Alba Spectrum Technologies ( http://www.albaspectrum.com ) – USA nationwide Great Plains, Microsoft CRM customization company, serving clients in Chicago, Houston, Atlanta, Phoenix, New York, Los Angeles, San Francisco, San Diego, Miami, New Orleans, Toronto, Montreal and having locations in multiple states and internationally
help@albaspectrum.com
|
