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
Dexterity Customization for Dynamics GP Evaluation Level Paper
When you are developer it is always a good idea to read technical manuals. But if you was just assigned to the IT team to decide if Dexterity is the right tool to customize your ERP application then first you need something which is in style of ‘easy reading papers’ or FAQ
Planning Dynamics GP Customization in Large Corporation
If you are reading this page then chances are high that you were not able to find ISV add-on and need customization project. Let’s talk about planning, quality assurance and future event such as version updates.
Dynamics GP Invoice Logo Attributed to Specific Company or Crossing the Borders of Three SOP Forms
Initial Great Plains Dynamics architecture had three SOP Invoice forms: Long, Short and Blank. Modern GP is popular in scenarios where you have more than three companies under one business entity umbrella
