From: Daintrees <p.d...@pa...> - 2004-05-28 07:15:46
|
Hi Nicolaus, I have not explored the raft of differing standards. I only have a basic knowledge that they exist. My company uses UN/EDIFACT standard messages. UN/EDIFACT is the super-set on which EANCOM is based EANCOM covers 99.9% of all potential data transfer requirements. My focus really has been on pulling out the useful stuff from the other stuff which whilst cool does not add significant value for most businesses. Larger businesses where volumes of shipping advises and other more obscure EDI messages are in significant enough volume to justify the pain, can pay for this stuff to be developed specifically for them. However, all businesses need to be able to send and receive orders and invoices so these have been my focus. The company I work for is a member of EAN - the global body that administers the unique company prefixes for barcodes. I obtained a copy of their EANCOM EDI standard from the local EAN office on CD - they have them worldwide. I also asked them if they were ok with me using their standard - I had no reply. Their standard is widely used down-under as a more pragmatic sub-set of the massive UN/EDIFACT standard which caters for more than the vast majority of data requirements - it is still very extensive. Since EANCOM is a subs-set of UN/EDIFACT, my code is therefore UN/EDIFACT compliant. The documentation on EANCOM is massive the order message docs are over 100 pages. What do you mean by an EDI server solution. If you mean like a VAN set up that converts between all the various standards.... definitely not keen! I am working to avoid VANs althogether, (I hate intermediaries with a passion) I want to break the barriers to businesses talking directly to each other this is why I have put such a lot of effort into EDI. It is a major mission to code up these things. Several businesses with web-erp or other EANCOM EDI software can send and receive orders electronically and send and receive invoices automatically without the need for VANs. If you mean develop web-erp further to make EDI available to the masses then yeap - lets go. I have sending invoices sorted ... I think. I am 50% through receiving purchase orders to create a sales order. I am yet to send purchase orders and receive sales invoices - converting to purchase invoices, I don't think I will attempt this one either unless someone desparately wants it. I looked a long time - the longer the look the more daunting the prospect - before embarking on this. In the end I just dived in. There is some other open-source project which purports to do edi conversions. However, it is complex - a packaged solution with all the complexity under the hood is what is required in my view, just coding up the EDI messages in isolation from the rest of the business logic is only half the story, the integration to the back end of the business software will always be a mission. Good luck with your project. Phil ----- Original Message ----- From: "Nicolaus Sommer" <nic...@je...> To: "'Daintrees'" <p.d...@pa...> Sent: Friday, May 28, 2004 2:20 PM Subject: RE: WebERP > Dear Phil, > I would love to, but I'm confused about all these EDI "standarts" > > EANCOM > UN/CEFACT > EDIFACT > ASC X12 > ASC X12/XML > HIPAA > VICS > UCS > > .... Some are related - others not - I have a hard time to find up to date > specs. > > I'm a software developer and just start pre planning on EDI ... > Would you be interested in (co)-developing a PHP/mySQL based EDI processing > server solution? > > Best regards, > Nicolaus Sommer > > > -----Original Message----- > From: Daintrees [mailto:p.d...@pa...] > Sent: Thursday, May 27, 2004 18:03 > To: nic...@je... > Cc: web...@li... > Subject: Re: WebERP > > > > Q: To what standart is the EDI export/import programmed - do you have > > any documentation for the implemented EDI interface? > > EANCOM > > There is some stuff in the latest manual - on CVS. Currently only invoices > can be sent to customers using EDI - and I was looking for a beta tester > (have I found one) to work with me to get EANCOM orders received going. > > > Phil > > > > |