Microsoft Great Plains Integration ScenariosEDI, eCommerce

by : Andrew Karasev

Let’s consider and compare the methodologies, integration and software development tools, programming techniques and customization option

  1. EDI.? Electronic Document Interchange is relatively matured technology and typically it is realized in the form of fixed length text formatted files or text streams.? Newer approach may consider new generation of similar to EDI in concept XML streams.? When we are talking about GP, we should expect two types of EDI integrations – when you are vendor (in this case you receive EDI formatted either Sales Order Processing orders or invoices or Accounts Receivables invoices); and when you are customer (in this case you place EDI purchase orders to your vendors).? From the technology standpoint, EDI is not really difficult in standard and even custom realization and programming.? Microsoft Dynamics GP, starting with version 8.0, is supported on the only DB platform – Microsoft SQL Server.? Current version of Microsoft Great Plains is 10.0, available on MS SQL Server 2005 or 2000.? You program EDI streams with SQL select command, and you format text fields with cast or convert constructions.? When you import external EDI streams you, it is when you create SOP Invoices, you should consider utilizing eConnect
  2. eCommerce. If you are e-commerce programmer, please invest your time in eConnect technology learning.? You probably heard about eConnect and about the fact that it was dedicated initially to e-commerce software developers.? We would like to sort of popularize eConnect and say this – if you do eCommerce integration from scratch, you have to feed eCommerce orders and invoices into GP tables: SOP10100, SOP10200.? However, you should know that eConnect already has this job done for you in eConnect business objects – encrypted stored procedures.? There are several situations when you should break through eConnect restrictions.? First one is the fact that eConnect replicates Dexterity business logic (DYNAMICS.DIC is Microsoft Dexterity dictionary, where all the core modules business logic is stored) and even trusting astonishing SQL Server performance, you can still have concerns that eConnect might be a bit slow, if you transactions volume crosses thousand records per session.? If eConnect performance is in question, you may consider doing simplified integration in SQL stored procedures using insert into logic.? The second eConnect limitation is absence of posting logic – in order to post SOP batches you will need to deploy Albaspectrum posting server