Microsoft Dynamics GP Integration: FAQ & Highlights
by: Andrew Karasev
Microsoft Great Plains version 10.0, 9.0, 8.0 is only supported on Microsoft SQL Server DB platform, which opens the whole world of SQL scripting for SQL programmer, however in order to follow GP business logic and do not “harm” – you should be familiar with table structure and how records are distributed in MS SQL company and DYNAMICS databases. So, please first read about other integration options and make a decision on the next step:
* GP Integration Manager. This tool is rather end-user and very intuitive, however if you are VBA programmer (if you did VBA scripting for MS Excel or Access, something like that) – you can advance IM integrations with custom logic: pre-document scripts allow you to manipulate such properties as invoice or payment date. Also in Integration Manager you can do data translation – if you integrate vendor invoices and you have your company corresponding vendor number – here translation does the job
* eConnect. If you are C# or VB.Net developer – you may like this tool. It allows you to create master records: customer, vendor, employee, account, etc. as well as work transactions: SOP Order, Invoice, POP Purchase Order, things like that. Technologically eConnect core business objects are written in SQL stored procedures, which you can’t change – but there is no need as they are organized in the form of GP objects for your convenience
* SQL Scripting. Please, think first about eConnect – this is the collection of SQL stored procs – isn’t it what you need? When you are thinking about your own SQL stored procedures to integrate something with GP – do you plan to enter new master records and transactions: customer and Invoice? If our suspicion is close – please think about deploying eConnect. If you think that you got to use direct SQL scripting, then try this approach – enter in GP the transaction you plan to import via SQL scripts and analyze in details records distribution. Good example would be SOP order: SOP10100, SOP10200 tables, assuming you don’t do inventory items allocation. Then try to imitate it in your SQL stored procedures. SQL scripting might be too challenging, even if you are professional SQL DBA or developer – GP has Microsoft Dexterity architecture with such tricks as DEX_ROW_ID, for example. Also GP tables consistency is validated through so-called “check links” process – if you SQL feeding was not 100% accurate – check links might wipe out your records
* Dexterity Integrations. If you do not have Dex development experience or formal training, we don’t recommend you to develop in Dexterity – this is too complex and dex in turn is too proprietary. Dexterity allows you to do to the GP internal world as deep as you need or wish. Dexterity is not object oriented language, so you have to program it in old-good-days style.
* Autoposting Server. Supported by Albaspectrum, and written in Dexterity – it allows you to extend eConnect with automated posting from your eCommerce application. All you need is dedicated GP workstation and user license with custom dexterity application – Autoposting server installed. As the developer you will need to populate approved for posting batches table
About The Author
Andrew Karasev, Alba Spectrum Group,
http://www.albaspectrum.com [email protected] 1-866-528-0577, 1-630-961-5918, serving Microsoft Dynamics GP USA and Canada nationwide: Toronto, Montreal, Vancouver, Calgary, Windsor, New York, San Francisco, Los Angeles, Miami, Orlando, Pittsburg, Toledo, Indianapolis, Detroit, Philadelphia, Boston, Washington, Seattle, San Diego, Phoenix, Austin. Local service is available in Chicago and Houston metros: Rosenberg, Katy, Richmond, Dallas, Galveston, Sugar Land, Naperville, Wheaton, Plainfield, Aurora, Wheaton, Downers Grove, Lisle, Oakbrook, Morris, Marseilles, Joliet, Montgomery, Oswego, DeKalb. With reasonable travel we serve Springfield, Bloomington, Normal, Peoria, LaSalle, Ottawa, Dixon
