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

[Bernd Eckenfels <b.eckenfels@seeburger.de>]

Title:

Hey Peter,

> 002401c17d42$5d0affc0$0101a8c0@peter">
> > The question is, why the isnt done by WebEDI of course is still
> > unanswered.
> >     
>
> 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).
> 002401c17d42$5d0affc0$0101a8c0@peter">
> The system includes Libraries which can be incorporated into accounting
> software.
>       
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.
      
> 002401c17d42$5d0affc0$0101a8c0@peter">
>   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).
        
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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))
          
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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.
            
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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
:)
              
Greetings
Bernd
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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.
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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.
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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).
                    
> 002401c17d42$5d0affc0$0101a8c0@peter">
> 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.
                      
Greetings
bernd