Free Ecommerce Hosting Web Site Designs | B2B

Microsoft Great Plains eCommerce - Stored Procedures Approach

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%.

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:

1. 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.

2. 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 developer-friendly but if you create sample transactions in Great Plains you can figure out where data should be populated.

3. 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.

4. 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.

5. 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.

 

Google
 Copyright 2003 - 17 All rights reserved.