EDI: Electronic Document Interchange for Microsoft Great Plains – overview for Software Developer/Programmer/DBA

Sep 24
21:00

2004

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

... Great Plains - ... Business ... ... and ERP system, ... targeted to mid-size - now, with ... and ... ... of its database - ... SQL Ser

mediaimage

Microsoft Great Plains - Microsoft Business Solutions accounting and ERP system,EDI: Electronic Document Interchange for Microsoft Great Plains – overview for Software Developer/Programmer/DBA Articles originally targeted to mid-size - now, with advancements and increasing reliability of its database - Microsoft SQL Server, Great Plains is attractive solution for large corporation. Big companies usually have purchasing and order processing automation via so-called Electronic Document Interchange or EDI. EDI was introduced long time ago for UNIX systems and in most of the cases appears in the form of Header, Lines and Trailer of predefined fixed position fields.
We would like to give you - programmer, software developer, database administrator the primary clues on producing EDI formatted text from Microsoft Great Plains database. Please, note however that Great Plains here is taken as the example, similar approach will work for other SQL based systems: Navision (SQL Database or C/SIDE database), Microsoft RMS, Solomon as well as Oracle and other non-Microsoft products. In the case of non-SQL system, such as old Great Plains Dynamics, ACCPAC on Pervasive SQL - IDE interface will involve ADO/ODBC or Microsoft Access programming.
1. Sample Query – The query below uses CAST construction to make the result fixed length and meet the positioning. Plus the unionizing allows to produce Header and Detail in one select statement. Here we are dealing with work Sales Documents
select
case
when b.LNITMSEQ=c.LNITMSEQ+1 and b.CMPNTSEQ=c.CMPNTSEQ+1 then CAST('Header' as char(10))
else CAST('Detail' as char(10))
end
as FIELD0,

case
when b.LNITMSEQ=c.LNITMSEQ+1 and b.CMPNTSEQ=c.CMPNTSEQ+1 then cast(a.CUSTNAME as char(65))
else cast(cast(b.QTYDMGED as decimal(19,5)) as char(65))
end
as FIELD01,

case
when b.LNITMSEQ=c.LNITMSEQ+1 and b.CMPNTSEQ=c.CMPNTSEQ+1 then CONVERT(char(51), a.DOCDATE, 101)
else cast(b.ITEMDESC as char(51))
end
as FIELD03

--Additional fields go here
from SOP10100 a join SOP10200 b on a.SOPTYPE=b.SOPTYPE and a.SOPNUMBE=b.SOPNUMBE join
RM00101 d on a.CUSTNMBR=d.CUSTNMBR
join
(select SOPTYPE as SOPTYPE, SOPNUMBE as SOPNUMBE,
LNITMSEQ
as LNITMSEQ,
CMPNTSEQ
as CMPNTSEQ from SOP10200
union
select SOPTYPE as SOPTYPE, SOPNUMBE as SOPNUMBE, MIN(LNITMSEQ)-1 as LNITMSEQ, MIN(CMPNTSEQ)-1 as CMPNTSEQ from SOP10200
group by SOPTYPE, SOPNUMBE
) c on a.SOPTYPE=c.SOPTYPE and a.SOPNUMBE=c.SOPNUMBE
and ((b.LNITMSEQ=c.LNITMSEQ and b.CMPNTSEQ=c.CMPNTSEQ) or (b.LNITMSEQ=c.LNITMSEQ+1 and b.CMPNTSEQ=c.CMPNTSEQ+1))
left join SOP10106 udf on a.SOPTYPE=udf.SOPTYPE and a.SOPNUMBE=udf.SOPNUMBE
where a.ADDRESS3<>'Exported' and
a.SOPTYPE=3 and upper(d.USERDEF2)='YES'
order by a.SOPTYPE, a.SOPNUMBE, b.LNITMSEQ asc
2. Mark processed documents - for this reason we use SOP10100.ADDRESS3 field - which was not used in Great Plains Dynamics/eEnterprise version 6.0:
update SOP10100 set ADDRESS3='Exported' where SOPTYPE=3
3. Communication with UNIX EDI Client or Server – each case requires individual approach. You may have to assign the file directory, exposed to the UNIX system or use old DOS command to move the file, or you can have automatic email. Good idea is to write communication application in your favorite programming language
4. Scheduled DTS Package - you should probably create DTS package to do all the steps: call SQL Query and save it as a file, then call DOS command or simple EXE application - which does communicate with UNIX
Happy programming! if you want us to do the job - give us a call 1-866-528-0577! help@albaspectrum.com