Andrew Karasev

Great Plains Consultant: EDI solutions for Dynamics GP

Microsoft Dynamics GP has various EDI (Electronic Document Interchange) add-ons and third party modules, where you can map your EDI code to either expose GP documents, such as Vendor Purchase Orders to EDI complaint vendors or import Sales Orders or Invoices from EDI channel to your SOP module, as two popular examples. 

In certain cases purchasing add-on may not be feasible due to the simplicity of your requirements or paradoxically – their complexity, where you would like to control EDI mapping in-house or with trusted Great Plains Dynamics consultant.  This publication is targeted to EDI technical people, and as such may look too programmer oriented, however we tried to make it readable for technology savvy executive.  Let’s review briefly both scenarios: export and import:

1.       Exporting EDI compliant text code.  Typically EDI code has fixed length format with Header, Lines, and various Trailers.  Simple approach to produce this fixed length formatted text file is to save SQL select statement, where you unionize the portions and precisely format each field.  If you are exporting Purchase Orders, then likely you are dealing with Purchase Order Processing module tables: POP10100, POP10110.  Then what you need to do is to mark your exported Purchase Orders in custom table as exported.  Feel free to create this export status table in GP company database.

2.       Importing EDI file to GP.  Here you need to consider pushing documents to Great Plains via eConnect programming, assuming that automatic batch posting is not required.  If Autoposting is required, we recommend you to deploy Alba Spectrum Posting Server or Autopost.  You open incoming EDI text file with OLEDB text driver.   Then the options are multiple – our favorite is to read text file into temporary table.  In this case you will have typical field names: F1, F2, F3 – to make your grouping, sorting and having clauses elegant.  Another popular alternative is to establish SQL linked server to your text file, however this construction might be too powerful and not really required on that level

3.       ODBC text file driver limitations.  ODBC supports the subset of standard SQL language only and you will see multiple limitations: case, text functions and other standard SQL constructions are not supported by ODBC SQL

4.       EDI and Great Plains Dexterity.  If you need seamless integration with GP user interface, GP Dexterity might be the tool of choice.  Dex allows you to call either Dex SQL compliant cursors, or call directly SQL statements or stored procedures to do the job, already described in the paragraphs above

Article Tags: Great Plains, Text File

Source: Free Articles from ArticlesFactory.com

ABOUT THE AUTHOR