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 Buy Orders to EDI complaint vendors or import Sales Orders or Invoices from EDI channel to your SOP module, as two standard examples. In certain cases purchasing add-on may not be feasible due to the simplicity of your requirements or ironically – their complexity, where you want to control EDI mapping in-house or with trusted Fantastic Plains Dynamics consultant. This publication is targeted to EDI technical people, and as such may look too programmer oriented, but we tried to make it readable for technology savoir-faire executive. Let’s review briefly both scenarios: export and import:
1. Exporting EDI compliant text code. Typically EDI code has fixed part format with Header, Lines, and various Trailers. Simple approach to produce this fixed part formatted text file is to save SQL select statement, where you unionize the parts and precisely format each field. If you are exporting Buy Orders, then likely you are dealing with Buy Order Processing module tables: POP10100, POP10110. Then what you need to do is to mark your exported Buy Orders in custom table as exported. Feel free to make this export status table in GP company database.
2. Importing EDI file to GP. Here you need to consider pushing documents to Fantastic 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. A further standard alternative is to establish SQL linked server to your text file, but this construction might be too powerful and not really required on that amount
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 Fantastic 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 frankly SQL statements or stored procedures to do the job, by now described in the paragraphs above