Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...

[James Wydenbach <james@bitdaemons.com>]

Hello Rachel, Todd, Fred, Duane and everybody else,

I've just picked this thread up (drawbacks of living in the UK and sleeping 
when most of the interesting discussions are going on!).

I thought I should draw your attention to the product which my company, 
BitDaemons, is developing, called Octimal, which, it seems, addresses many of 
the points in this thread:

- It is targetted at SME's
- It is an out-of-the-box, off-the-shelf solution
- A free, downloadable version will be released to SMEs
- It operates as a business-specific e-mail type system, offering the host 
company complete control over all outbound and inbound messages and residing
on their internal systems.
- It enables the transfer of XML-based (including UBL) documents between 
parties
- It enables this data to be seamlessly transferred between backend systems 
or viewed and edited by users as required.
- The viewing and editing of the data takes place in a rich user interface 
and the document can then be transferred to the company's backend data store 
or published to a variety of other formats as is the company's document 
policy.
- It is ebXML-compliant.

We demonstrated this product at the European Software Vendor's conference at 
eBES last month and, indeed, made the point that unless ebXML is widely 
adopted by SMEs then it will struggle to achieve its goals.

We believe Octimal will greatly benefit the take up of ebXML and are looking 
for partners to help us bring it to market.

Please forgive the plug, but as this thread has been discussing the need for 
a product with all the features that Octimal offers, I thought I should bring 
it to your attention.

Thanks,

James
www.bitdaemons.com


On Tuesday 23 April 2002 00:08, Fred Blommestein, van wrote:
> Rachel,
>
> You may differ with me, I don't with you.
> I also want it in a processable way AND in a viewable way. That's why XML
> was invented. I want the flexiblity at the receiver's side to set the level
> of integration without bothering the sender. ebXML IMO doesn't support that
> (yet).
>
> Fred
>
> <<< "Rachel Foerster" <rachelf@ix.netcom.com>  4/23  1:37a >>>
> Fred,
>
> This is where you and I differ....I want the data in a processable format.
> I don't want to look at it on my monitor. Until I can get it this way I'll
> continue with good old fashion paper. Even though I could go to various web
> sites to look at account details, etc., I don't because it's not convenient
> to the way I want to work.
>
> BTW, however, I do pay everything (and I mean everything...except my dry
> cleaner) with either AMX or via electronic payment through Quicken to
> CheckFree. No more checks/paper/cash!
>
> So....no right or wrong here....but herein lies a challenge....what DO
> these SME's want?
>
> Rachel
>
> -----Original Message-----
> From: Fred Blommestein, van [mailto:f.van.blommestein@berenschot.com]
> Sent: Monday, April 22, 2002 4:06 PM
> To: rachelf@ix.netcom.com; mike@rawlinsecconsulting.com;
> tboyle@rosehill.net; ckharvey@zaratechnology.com.sg
> Cc: ebxml-dev@lists.ebxml.org
> Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...
>
>
> Rachel,
>
> I agree, that ultimately I would like to do everything automatically
> through my Quicken system. But what if Quicken (or whatever accounting
> system I have)  does not support that (yet). Or doen't support that
> specific document or process.
>
> And you are wrong. I don't want merely to see the message on my monitor, I
> want to be able to retrieve more information if needed and give a response
> as well (and in the process I want my Quicken system to get the data it
> needs).
>
> Anyway what I need is a more flexible way of communication than receiving
> an electronic document that is a copy (but less readable) from the paper
> one.
>
> Fred
>
> <<< "Rachel Foerster" <rachelf@ix.netcom.com>  4/22 10:49p >>>
> Fred,
>
> Your concept seems to me to be one of requiring the receiver, i.e., the
> SME, to have to deal with the business message as a display on a monitor.
> That certainly doesn't get at the need to be able to automatically take the
> data into a system.
>
> As an SME I don't want to view the message, I want to take the data into
> Quicken! I want to view it only after it's in my application system and
> then make business decisions, such as whether to post or not and then pay
> or not. A big difference.
>
> Rachel
>
> -----Original Message-----
> From: Fred Blommestein, van [mailto:f.van.blommestein@berenschot.com]
> Sent: Monday, April 22, 2002 3:41 PM
> To: mike@rawlinsecconsulting.com; tboyle@rosehill.net;
> ckharvey@zaratechnology.com.sg
> Cc: rachelf@ix.netcom.com; ebxml-dev@lists.ebxml.org
> Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...
>
>
> Todd, others,
>
> I always understood that the added value of XML over EDI is that you can
> send XML to a simple browser, while for EDI you need expensive middleware.
> Yet the focus of ebXML seems to be a mere replacement of EDI, with
> expensive middleware, but only more complex.
>
> In my view ebXML will only be viable (but then very viable) if support for
> it is built in in operating systems and general utilities like browsers.
>
> To enable that, we should:
> - define a message service layer that is handled by (next version) browsers
> (and mobile phones)
> - define browser (and mobile phone) compatible "patterns" or transactions.
>
> A browser compatible "pattern" takes into account that a message (that is
> crowded with non human readable codes) is not just sent to the other end,
> but that the receiver (or his stylesheet) may decide what information he
> needs to retrieve additionally from the sender to take the next step.
>
> So the "logical" transfer (e.g. send a purchase order) may behave
> technically as a dialog, resulting in the same commitment.
>
> The challenge is to let this be transparent for the sender, who doesn't
> know (and doesn't care) whether the message goes to an SME or a
> multinational.
>
> Any thoughts?
>
> Fred van Blommestein
> Berenschot - EP-NL - OpenXchange
>
> <<< Todd Boyle <tboyle@rosehill.net>  4/22  9:59p >>>
> Me too.
>
> Mike Rawlins wrote:
> >Excuse me, but I can't help but violently disagree with most of this
> >sentiment!
> >[...]
> >We need better solutions, not bigger sticks...
> >
> >Christopher Harvey wrote:
> >>...my 0.02 cents worth is to ask all involved to understand
> >>   the needs of the SMEs but to use the big guys to force change.
>
> Here's one idea: a bettor's approach, or a PicoIPO:
>
>
> Dear SME Accounting Software vendor:
>
> I hereby offer to pay you to build a UBL interface on your
> product.  You will offer it for sale to your users.
>
> Together we will calculate how many unit sales it requires
> for you to recover the cost of the development.  You will
> repay me for my investment at a flat rate until you reach the
> breakeven sales.  Then you will pay me another $1000
> winnings, from any further incremental sales.  Then you
> can keep the sales proceeds after that.
>
> Stop arguing which came first, the chicken or the egg.
>
> Here is an egg.
>
> Todd
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>
>
>
>
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>
>
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>

-- 
James Wydenbach
BitDaemons Ltd
http://www.bitdaemons.com
tel: +44 (0)1252 326402