OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-dev] Off-the-shelf ebXML software packages

Hey Peter,

The question is, why the isnt done by WebEDI of course is still

Would love to hear where I can read about this.
It is quite simple. A Web Page allows you to upload and download files in a pre-specified format (could be XML, could be comma delimited files, could be excel or EDIFACT/X.12). It also allows you to render those files (into HTML or PDF for print) instead of downloading them.

It is called WebEDI because the small trading partner is using a Web Browser (no other software required) and the big copany is using EDI to send the files to the Web Server and receive files from the Web Server.

It is a tool for a Big Company to connect all trading partners with one interface. Typically they have 90% of their transactions integrated by EDI for 10% of their partners. And 90% of their partners only doing 10% of the transactions but those are 90% of the costs. (Because EDI is to expensive for them or they cant process/generate the EDI/XML Documents).
The system includes Libraries which can be incorporated into accounting
Thats excatly the problem. This is much to expensive. All Software Vendors of EDI Solutions offer those APIs and it is accepted with a high price only.

  You enter an order in the way you normally would into the
accounting system, then hit "Send" Instead of Print.
This is the normal mode of operation any desktop edi system with Data Entry Facility have (those have most of the time a mapping engine and a form designer added). But this is not a real solution, because the value of eBusiness is not having to type in transactions manually. Of course there is a small demad for this, but as I said you can solve this by Web Applications. (Web Apps have the advantage of easy and softwareless deployment and have the disadvantage of mising offline/batch support).

Bottom line is that I
provide the communication libraries, and a standard baseline interpretation.
The standard baseline is a problem. You can't enforce a Big customer to use "your" ebXML subset, if he has another one. You (as the small company) have to be flexible. This is the same like with ERP systems having a deault export format. Most likely this format is only accepted by your partner if you can force him, if you can pay him OR if your partner has a lot of other customers using the same ERP System. (that is one of the Reasons why ost of the Marketplace Vendors typically accept SAP XML-IDOCs and still they can't do that without some degree of customization at receiver or senders side (which is done in java and costly))

Also of importance is a catalog system, in which product codes are stored,
and pricing rules determined.
You mean you want to write an accounting software? Compelxity gets out of hand.

The point is that people don't seem to understand that (in New Zealand
anyway) 95% of businesses have access to a Computer and a Internet
connection, and therefore have access to email. It is also true that only
5% of businesses are using that technology to transfer business documents.
Well, instead of entering your orders in an application you can also put them into a spreadsheet and send them by email. No big differende.

I like the idea of having a small offline ebXML Client (supporting flexible entry forms, simple data transformation and simple printing, small product database, automated software update and so on) I would even support it's development. It wil even help to solve some EDI Problems (but only a few :)

The approach to date seems to be to convice people to create web sites
intergrated into back end systems. This just doesn't suit many businesses.
Those Web sites offer up and downloads quite frequently.
You don't want your statement on a web site - you want it as a file that you
can suck into your accounting system - same with invoices, orders etc.
Yes, but the problem is, that file you download is the same "garbage" as the file you get from your "ebXML" client. Both have to be transformed AND your software have to have an import interface (and all the data which is required by your accounting software has to be present). You get it... it is not that easy as soon as you start to integrate it with Backends on both sides.
This means that we are missing out on 90% of businesses because we don't
have something to offer. Think about the HUGE market for a product which
can communicate basic documents without fuss.
Well.. without integration it is called email and with integration it is a traditional B2B Integration Solution (Desktop Edition).

Its really a vision thing - I imagine a system which is almost as simple as
SMTP, and certainly as standard.
If you want to put some work into it, please contact me in private.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC