[ebxml-dev] Running ebXML on a chip...

[David Lyon <david.lyon@globaltradedesk.com>]

Mike,

> My point exactly.  What's your background David?  Is it business or is
> it technical?

It's both. I've worked as a Business Analyst and a Technologist. Now I'm
a Product Manager. I develop Technology products for business.

> If it were the latter, I think you would immediately know
> the difference between TCP/IP source code and software on CD-ROM vs.
> functionality that is physically burned onto a chip.

I have one of these kits. You develop on the PC with the development kit
and when you have a program written you upload it to the chip to run it.

Did I ever say that ebXML has to be "burnt" on a chip ? No. All I said
was that it could *run on* a chip. The way the program is stored on the
chip is entirely irrelevant. These days, eproms are a bit out of fashion.
Flash
ram is much more popular.

> Then again, maybe we just have a different understanding about what "on
> a chip" means.

Yeah, maybe you're talking about potato chips...

David Lyon
Product Manager
Global TradeDesk Exchange


----- Original Message -----
From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
To: "David Lyon" <david.lyon@globaltradedesk.com>
Cc: <ebxml-dev@lists.ebxml.org>
Sent: Wednesday, April 24, 2002 12:51 AM
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...
RATHOLE!


> RAT HOLE RAT HOLE RAT HOLE!!!
>
> I must be crazy to keep this going - I know I have better things to do.
>  See comment in-line.
>
> David Lyon wrote <snipped>:
>
> >Mike,
> >
> >>Neither says anything about an *embedded* ("on a chip") web server like
> >>Apache.
> >>
> >
> >I'm afraid you are wrong.
> >
> >The Rabbit chip comes with an excellent development kit which features a
> >full implementation of TCP/IP. You can check the link out yourself at:
> >
> >http://www.rabbitsemiconductor.com/products/rcm2200/rcm22_devkit.html
> >
> >To quote from their documentation:
> >
> >"Full TCP/IP source code is provided in addition to the Dynamic C
software
> >on CDROM. ICMP, HTTP (includes facilities for SSI, CGI routines, cookies,
> >and basic authentication), SMTP, FTP and TFTP (client and server)
> >capabilities are provided"
> >
> My point exactly.  What's your background David?  Is it business or is
> it technical?  If it were the latter, I think you would immediately know
> the difference between TCP/IP source code and software on CD-ROM vs.
> functionality that is physically burned onto a chip.
>
> All of the software mentioned here runs *on* the chip.  It is not hard
> coded "into" the chip.  Do you see the difference?
>
> Assuming that the light bulb has gone off, I think you'll understand my
> point about ebXML "on a chip" being a fantasy...
>
> Then again, maybe we just have a different understanding about what "on
> a chip" means.
>
> Now, I really do have better things to do.
>
> Cheers,
>
> >
> >
> >Anyway, maybe an ebXML implementation is a few months off. Who knows. I
know
> >that there are quite a few SMEs around the world that would love ebXML on
a
> >platform like this. So so simple...
> >
> >Best Regards
> >
> >David Lyon
> >Product Manager
> >Global TradeDesk
> >
> >----- Original Message -----
> >From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> >To: "David Lyon" <david.lyon@globaltradedesk.com>
> >Cc: <ebxml-dev@lists.ebxml.org>
> >Sent: Wednesday, April 24, 2002 12:00 AM
> >Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...
> >RAT HOLE!
> >
> >
> >>RAT HOLE ALERT - Here I go diving down...
> >>
> >>As I said, David, get real.  The first URL you pointed to says:
> >>
> >>"This new design takes integration to a new level and saves significant
> >>space, cost, weight, and assembly time for designers of embedded
> >>systems. PROMETHEUS is an ultra-integrated, ultra-rugged,
> >>ultra-efficient design ready for your industrial and commercial
> >>application."
> >>
> >>The second one has a similar write up.
> >>
> >>Neither says anything about an *embedded* ("on a chip") web server like
> >>Apache.
> >>
> >>
> >>David Lyon wrote:
> >>
> >>>Hi Mike,
> >>>
> >>>So you're trying to tell me that ebXML could never run on the following
> >>>hardware:
> >>>
> >>>http://www.diamondsystems.com/products/prometheus
> >>>
> >>>or
> >>>
> >>>http://www.rabbitsemiconductor.com/products/rcm2200/index.html
> >>>
> >>>Is there some sort of incompatability ? or something that I don't know
> >>>about.
> >>>
> >>>These devices already run web servers quite fine so I'm interested to
> >>>
> >know
> >
> >>>why ebXML couldn't be tacked on them as well.
> >>>
> >>>David
> >>>
> >>>----- Original Message -----
> >>>From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> >>>To: <ebxml-dev@lists.ebxml.org>
> >>>Sent: Tuesday, April 23, 2002 11:40 PM
> >>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...
> >>>
> >>>
> >>>>David,
> >>>>
> >>>>While we agree about SME requirements, I think your remedy is a bit on
> >>>>the edge of fantasy.  ebXML on a chip?   This reminds me of when
people
> >>>>were afraid that Microsoft was going to build EDI into Windoze.   I
can
> >>>>see an XML parser on a chip a lot sooner than ebXML, and I don't
expect
> >>>>to see a W3C schema validating parser on a chip any time soon.   We
> >>>>don't even have fully compliant parsers in software yet!
> >>>>
> >>>>Get real ;^)
> >>>>
> >>>>Mike
> >>>>
> >>>>David Lyon wrote:
> >>>>
> >>>>>Mike,
> >>>>>
> >>>>>You're absolutely right.
> >>>>>
> >>>>>>The main problem is not necessarily with the SME, but with
> >>>>>>the tools that are available to them.  Most would accommodate a big
> >>>>>>customer's request to do business electronically if it was cost
> >>>>>>effective for them to do so.
> >>>>>>
> >>>>>That's why I say that somebody has to go to Asia and produce ebXML on
a
> >>>>>chip.
> >>>>>
> >>>>>SMEs will be able to then afford the product. And you will be able to
> >>>>>
> >get
> >
> >>>an
> >>>
> >>>>>ROI providing that you can make it work.
> >>>>>
> >>>>>David Lyon
> >>>>>Product Manager
> >>>>>www.globaltradedesk.com
> >>>>>
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> >>>>>To: "Christopher Harvey" <ckharvey@zaratechnology.com.sg>
> >>>>>Cc: "'Todd Boyle'" <tboyle@rosehill.net>; <rachelf@ix.netcom.com>;
> >>>>><ebxml-dev@lists.ebxml.org>
> >>>>>Sent: Tuesday, April 23, 2002 5:15 AM
> >>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
> >>>>>
> >...
> >
> >>>>>
> >>>>>>Excuse me, but I can't help but violently disagree with most of this
> >>>>>>sentiment!  The main problem is not necessarily with the SME, but
with
> >>>>>>the tools that are available to them.  Most would accommodate a big
> >>>>>>customer's request to do business electronically if it was cost
> >>>>>>effective for them to do so.  In the current way of doing things
(and
> >>>>>>I'm afraid how ebXML may turn out the same way) it costs them more
to
> >>>>>>
> >do
> >
> >>>>>>business electronically than by other means.  And you blame *them*
for
> >>>>>>that?  That's exactly how the big guys work.  If they can't show an
> >>>>>>
> >ROI
> >
> >>>>>>on something, they won't do it.
> >>>>>>
> >>>>>>Your thinking reflects a big stick approach which I am increasingly
> >>>>>>seeing, with large buyers imposing financial penalties of all sorts
> >>>>>>
> >upon
> >
> >>>>>>their suppliers in force a shift of costs from the customer to the
> >>>>>>supplier.  Does this produce efficiencies?  In some cases yet, but
as
> >>>>>>often as not it forces the supplier to raise their prices so that
they
> >>>>>>can recover costs and still make a profit.  This is *not* a very
good
> >>>>>>
> >>>>>model.
> >>>>>
> >>>>>>We need better solutions, not bigger sticks...
> >>>>>>
> >>>>>>Christopher Harvey wrote:
> >>>>>>
> >>>>>>>Rachel,
> >>>>>>>
> >>>>>>>>What still amazes me is the assumption (apparently) on the part of
> >>>>>>>>
> >the
> >
> >>>>>>>large
> >>>>>>>
> >>>>>>>>enterprise is that if they get their needs meet the small guys
will
> >>>>>>>>
> >>>>>stand
> >>>>>
> >>>>>>>>up, salute and march on.
> >>>>>>>>
> >>>>>>>Very true but... I am increasingly of the opinion that unless we
use
> >>>>>>>
> >>>the
> >>>
> >>>>>>>power of the big guys down onto the SMEs, the latter will not
bother
> >>>>>>>
> >to
> >
> >>>>>do
> >>>>>
> >>>>>>>anything.
> >>>>>>>
> >>>>>>>SMEs do not have much of a collective voice except the scream that
> >>>>>>>
> >will
> >
> >>>>>come
> >>>>>
> >>>>>>>when they big guys hit them were it hurts. So, can we blame the big
> >>>>>>>
> >>>guys
> >>>
> >>>>>for
> >>>>>
> >>>>>>>"taking charge"?
> >>>>>>>
> >>>>>>>As you may gather, my patience with (some... most) SMEs is wearing
> >>>>>>>
> >>>thin.
> >>>
> >>>>>The
> >>>>>
> >>>>>>>average SME will ignore change until it is forced otherwise (at
least
> >>>>>>>
> >>>in
> >>>
> >>>>>>>this part of the world). We are slowly getting more and more of the
> >>>>>>>
> >big
> >
> >>>>>>>corporations telling our SMEs: "Do it electronically, or lose the
> >>>>>>>
> >>>>>business".
> >>>>>
> >>>>>>>Good, about bl**dy time.
> >>>>>>>
> >>>>>>>The SMEs have only themselves to blame. I am new to ebXML but 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.
> >>>>>>>
> >>>>>>>Regards
> >>>>>>>Chris Harvey
> >>>>>>>Zara Technology Pte Ltd
> >>>>>>>Singapore
> >>>>>>>
> >>>>>>>----- Original Message -----
> >>>>>>>From: "Rachel Foerster" <rachelf@ix.netcom.com>
> >>>>>>>To: "'Christopher Harvey'" <ckharvey@zaratechnology.com.sg>; "'Todd
> >>>>>>>
> >>>>>Boyle'"
> >>>>>
> >>>>>>><tboyle@rosehill.net>
> >>>>>>>Cc: <ebxml-dev@lists.ebxml.org>
> >>>>>>>Sent: 23 April 2002 01:17
> >>>>>>>Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
Components
> >>>>>>>
> >>>...
> >>>
> >>>>>>>>Chris,
> >>>>>>>>
> >>>>>>>>Your comments are on the mark! I've personally been a bit dismayed
> >>>>>>>>
> >>>over
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>>life history of the ebXML initiative that what once started out to
> >>>>>>>>
> >>>have
> >>>
> >>>>>a
> >>>>>
> >>>>>>>>focus on "inclusion" of the SME and their needs has instead, at
> >>>>>>>>
> >least
> >
> >>>in
> >>>
> >>>>>>>my
> >>>>>>>
> >>>>>>>>viewpoint, clearly moved over into the domain of the large
> >>>>>>>>
> >enterprise
> >
> >>>>>and
> >>>>>
> >>>>>>>>what they need/want.
> >>>>>>>>
> >>>>>>>>What still amazes me is the assumption (apparently) on the part of
> >>>>>>>>
> >the
> >
> >>>>>>>large
> >>>>>>>
> >>>>>>>>enterprise is that if they get their needs meet the small guys
will
> >>>>>>>>
> >>>>>stand
> >>>>>
> >>>>>>>>up, salute and march on. If the SME's needs are not truly
addressed
> >>>>>>>>
> >>>>>here,
> >>>>>
> >>>>>>>as
> >>>>>>>
> >>>>>>>>I said during one of my ebXML Marketing Work Group updates to the
> >>>>>>>>
> >>>ebXML
> >>>
> >>>>>>>>plenary, my personal opinion is that the ebXML effort will have
> >>>>>>>>
> >>>failed.
> >>>
> >>>>>>>>Rachel
> >>>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: Christopher Harvey [mailto:ckharvey@zaratechnology.com.sg]
> >>>>>>>>Sent: Sunday, April 21, 2002 9:09 PM
> >>>>>>>>To: Todd Boyle
> >>>>>>>>Cc: ebxml-dev@lists.ebxml.org
> >>>>>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
> >>>>>>>>
> >Components
> >
> >>>>>>>>...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Todd,
> >>>>>>>>
> >>>>>>>>Extremely well put. It's somehow comforting to know that SMEs in
the
> >>>>>>>>
> >>>US
> >>>
> >>>>>>>have
> >>>>>>>
> >>>>>>>>the same 'mentality' as SMEs here in Asia.
> >>>>>>>>
> >>>>>>>>The big gap to be bridged is in getting SMEs to understand that
> >>>>>>>>
> >there
> >
> >>>is
> >>>
> >>>>>a
> >>>>>
> >>>>>>>>direct financial benefit to be had; opposing that is their belief
> >>>>>>>>
> >that
> >
> >>>>>>>their
> >>>>>>>
> >>>>>>>>data must remain 'secret' (as it had for generations - a necessity
> >>>>>>>>
> >>>when
> >>>
> >>>>>>>more
> >>>>>>>
> >>>>>>>>than one set of books have been historically kept).
> >>>>>>>>
> >>>>>>>>Rachel is absolutely correct when she says: It's a business
> >>>>>>>>
> >imperative
> >
> >>>>>and
> >>>>>
> >>>>>>>>necessary now and into the future to be able to exchange
unambiguous
> >>>>>>>>
> >>>>>data.
> >>>>>
> >>>>>>>>As a tech company, we know that. Our government knows that. But
> >>>>>>>>
> >>>getting
> >>>
> >>>>>>>SMEs
> >>>>>>>
> >>>>>>>>to understand that is a whole different uphill struggle.
> >>>>>>>>
> >>>>>>>>ebXML is an excellent initiative but... the real SMEs, the
> >>>>>>>>
> >mass-market
> >
> >>>>>>>small
> >>>>>>>
> >>>>>>>>ones, with 50 or usually less, employees - which make up the vast
> >>>>>>>>
> >>>>>majority
> >>>>>
> >>>>>>>>of companies - have a mindset that you would not believe unless
you
> >>>>>>>>
> >>>have
> >>>
> >>>>>>>>been exposed to it. For the success of ebXML, and e-commerce in
> >>>>>>>>
> >>>general,
> >>>
> >>>>>>>it
> >>>>>>>
> >>>>>>>>is imperative that all involved with these important initiatives
> >>>>>>>>
> >have
> >
> >>>a
> >>>
> >>>>>>>good
> >>>>>>>
> >>>>>>>>grasp of the SME mindset.
> >>>>>>>>
> >>>>>>>>I hope this is not drifting off topic but it is vital that XML
> >>>>>>>>
> >>>potential
> >>>
> >>>>>>>>does not become solely the domain of the big players...
> >>>>>>>>
> >>>>>>>>Regards
> >>>>>>>>Chris Harvey
> >>>>>>>>Zara Technology Pte Ltd
> >>>>>>>>Singapore
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>----- Original Message -----
> >>>>>>>>From: "Todd Boyle" <tboyle@rosehill.net>
> >>>>>>>>To: <rachelf@ix.netcom.com>
> >>>>>>>>Cc: <ebxml-dev@lists.ebxml.org>
> >>>>>>>>Sent: 22 April 2002 07:56
> >>>>>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
> >>>>>>>>
> >Components
> >
> >>>>>...
> >>>>>
> >>>>>>>>>At 09:36 AM 4/21/02, Rachel Foerster wrote:
> >>>>>>>>>
> >>>>>>>>>>It's a business imperative and necessary now and into the future
> >>>>>>>>>>to be able to exchange unambiguous data. And personally I
believe
> >>>>>>>>>>
> >>>the
> >>>
> >>>>>>>>>>future will be **not** the shipping off to a business partner
data
> >>>>>>>>>>
> >>>or
> >>>
> >>>>>>>>>>documents, etc. but providing real time controlled access to the
> >>>>>>>>>>
> >>>>>>>>necessary
> >>>>>>>>
> >>>>>>>>>>information transparently between enterprises so that
> >>>>>>>>>>
> >>>cross-enterprise
> >>>
> >>>>>>>>>>business processes can execute to the desired outcome.
> >>>>>>>>>>
> >>>>>>>>>As more and more small businesses have always-on connections
> >>>>>>>>>to the internet, sooner or later it will dawn on them to expose
at
> >>>>>>>>>least some limited views or query interfaces to their customers
> >>>>>>>>>and suppliers.
> >>>>>>>>>
> >>>>>>>>>Small businesses often have only one person performing all roles
> >>>>>>>>>that interface a particular customer or supplier, and accordingly
> >>>>>>>>>have no need for business process management. The cost of
updating
> >>>>>>>>>all the statuses and stages of a BP exceed their benefit.  Cell
> >>>>>>>>>
> >>>phones,
> >>>
> >>>>>>>>>headsets, and the collapse of long distance have made it even
> >>>>>>>>>
> >cheaper
> >
> >>>>>>>>>to handle exceptions.
> >>>>>>>>>
> >>>>>>>>>I don't wish to diminish the usefulness of ebXML BP in any way,
for
> >>>>>>>>>Enterprise or other value chains where they are appropriate!  But
> >>>>>>>>>I think the exchange of documents remains the best potential
> >>>>>>>>>way to get ebXML in the door of SMEs.  And, once they gain some
> >>>>>>>>>familiarity with it, they will be much closer to supply chain
> >>>>>>>>>
> >>>>>>>integration
> >>>>>>>
> >>>>>>>>>or other BP scenarios.  Here is one fictitious dialog for
> >>>>>>>>>your entertainment
> >>>>>>>>>
> >>>>>>>>>Todd Boyle CPA
> >>>>>>>>>AR/AP everywhere  www.arapxml.net
> >>>>>>>>>
> >>>>>>>>>Let's take a break, and get beat up by a small busieness
owner....
> >>>>>>>>>
> >>>>>>>>>Q:  "Why should I allow my customer or supplier to see the
purchase
> >>>>>>>>>and sale data in *my* accounting system?? "
> >>>>>>>>>
> >>>>>>>>>A: "you already do.  Whenever you send a PO or an invoice. "
> >>>>>>>>>
> >>>>>>>>>Q:  Yeah but why should I allow them to see their Account
> >>>>>>>>>
> >Receivable
> >
> >>>>>>>>>page, or Account Payable, in *my* system?
> >>>>>>>>>
> >>>>>>>>>A:  You already do, whenever you send them a statement.
> >>>>>>>>>
> >>>>>>>>>Q.  Yeah, but I never send statements until they have been
reviewed
> >>>>>>>>>at the end of the month and the bank account is reconciled to
find
> >>>>>>>>>all the mistakes in our posting payments.
> >>>>>>>>>
> >>>>>>>>>A.  Ok then why don't you expose a view of the invoices now,
> >>>>>>>>>and expose the reviewed statements at the end of the month?
> >>>>>>>>>You don't have to change your procedures at all.  Too bad your
bank
> >>>>>>>>>is so unhelpful http://www.gldialtone.com/transaction04.htm
> >>>>>>>>>
> >>>>>>>>>Q.  Well why should I do this, what's the payoff for me?
> >>>>>>>>>
> >>>>>>>>>A.  Some of your customers might pay you sooner.
> >>>>>>>>>
> >>>>>>>>>Q.  Yeah but all my good customers already pay me on time,
> >>>>>>>>>and my bad customers, I don't think they have the intelligence
> >>>>>>>>>to use a computer.
> >>>>>>>>>
> >>>>>>>>>A.  Maybe when they can login and see their account they will
> >>>>>>>>>understand it better.  Maybe they are paying their other
suppliers
> >>>>>>>>>sooner than they are paying you. Why don't you try emailing them
> >>>>>>>>>their statements more often.
> >>>>>>>>>
> >>>>>>>>>Q.  Yeah but what are you trying to sell me?  You're just trying
> >>>>>>>>>to capture me into a central server or single-vendor software.
> >>>>>>>>>
> >>>>>>>>>A.  Sharing views *directly* with trading partners is the exact
> >>>>>>>>>opposite of being trapped in a portal model.  Today, you are
> >>>>>>>>>trapped in two separate portal models:  first, you are trapped in
> >>>>>>>>>your local software with no electronic interface...
> >>>>>>>>>
> >>>>>>>>>Q.  Yeah but what am I supposed to "Interface" with?  There is
> >>>>>>>>>no standard. Nobody else has any "Interface" either.
> >>>>>>>>>
> >>>>>>>>>A.  Do you vote?
> >>>>>>>>>Q.  Yes.
> >>>>>>>>>A.  Do you make charitable contributions?
> >>>>>>>>>Q.  Yes.
> >>>>>>>>>A.  How much did you contribute last year?
> >>>>>>>>>Q.  None of your business.
> >>>>>>>>>A.  Transaction integration helps the planet and it doesn't
> >>>>>>>>>       cost you anything.
> >>>>>>>>>
> >>>>>>>>>Q.  What do you mean??
> >>>>>>>>>
> >>>>>>>>>A.  You're cutting down the paper consumption, getting
> >>>>>>>>>vehicles off the road, cutting trips to banks and post offices.
> >>>>>>>>>You're saving labor. People can do more useful things.
> >>>>>>>>>
> >>>>>>>>>Q.  Yeah but what do you mean, "Free"?
> >>>>>>>>>
> >>>>>>>>>A.  Do you already do accounting work, posting all your sales
> >>>>>>>>>and purchases?
> >>>>>>>>>
> >>>>>>>>>Q.  Yes.
> >>>>>>>>>
> >>>>>>>>>A.  Then exposing the data to the trading partner costs
effectively
> >>>>>>>>>nothing. You don't have to compose any new documents. In fact,
> >>>>>>>>>the trading partner can freeload off your data entry work.  They
> >>>>>>>>>simply click "OK" to suck your data into their computer and post
> >>>>>>>>>
> >it.
> >
> >>>>>>>>>Q.  Yes.  But where is the software to do this??
> >>>>>>>>>
> >>>>>>>>>A. There are modules in the open source ebXML projects, and in
> >>>>>>>>>the VARs and developer communities of most of the accounting
> >>>>>>>>>platforms.
> >>>>>>>>>
> >>>>>>>>>Q.  Why that's ridiculous.  You're bullsh*itting me.
Integration
> >>>>>>>>>always costs megabucks.   I have been burned many times in
> >>>>>>>>>the past by computer consultants.
> >>>>>>>>>
> >>>>>>>>>A.  In the past, the N-squared problem required a separate
> >>>>>>>>>software solution for every combination of thousands of software
> >>>>>>>>>products, that is, *millions* of adapters to connect with each
> >>>>>>>>>
> >other.
> >
> >>>>>>>>>Since ebXML is a common format, each accounting platform only
> >>>>>>>>>needs one adapter.
> >>>>>>>>>
> >>>>>>>>>Q.  Well, I don't believe you.   Anyway, you said I am already
> >>>>>>>>>locked into  *two* different portal traps. What's the other one?
> >>>>>>>>>
> >>>>>>>>>A. You are trapped in the banking system with no other way to
> >>>>>>>>>settle ARs or APs except by running payments through banks
> >>>>>>>>>for each and every payment.  That wrecks your bookkeeping and
> >>>>>>>>>your trading partner's bookkeeping, since banks only process
> >>>>>>>>>payment data and block all the transaction data between small
> >>>>>>>>>businesses.
> >>>>>>>>>
> >>>>>>>>>Q.  That's right.  So, what good is AR/AP integration between me
> >>>>>>>>>and my trading partner?
> >>>>>>>>>
> >>>>>>>>>A.  Settlement intermediaries such as accounts receivable factors
> >>>>>>>>>can't be cheap today because the data is so confused.  But even
> >>>>>>>>>a robot can do settlement if data is good.  And if
collateralized.
> >>>>>>>>>What you are doing is uncoupling the interest cost and the risk,
> >>>>>>>>>which cannot be avoided.  You are making the mechanics of
> >>>>>>>>>
> >accounting
> >
> >>>>>>>>>and settlement cheaper.
> >>>>>>>>>
> >>>>>>>>>Derivatives, promissory notes or digital cash become more
> >>>>>>>>>
> >practical,
> >
> >>>>>>>>>when you have high quality data.  Do you think global
corporations
> >>>>>>>>>all write checks or bank transfers to each other?  at the end of
> >>>>>>>>>each month?  Not.
> >>>>>>>>>
> >>>>>>>>>Q.  OK you're telling me to provide a SOAP interface on my ARs
> >>>>>>>>>to my customers, and my APs to my suppliers???
> >>>>>>>>>
> >>>>>>>>>A.  Yes.
> >>>>>>>>>
> >>>>>>>>>Q.   Go away.  That's just not the way we do business in podunk.
> >>>>>>>>>
> >>>>>>>>>A.  Ok tell you what.   Why don't you pass me your ARs and APs
> >>>>>>>>>in UBL, in ebXML core components format, every time you do a
> >>>>>>>>>purchase or a sale.   You show me how much it's costing you,
> >>>>>>>>>screwing around with AR and AP, your banking and bank
> >>>>>>>>>reconcilation, and other settlement after the conclusion of a
sale.
> >>>>>>>>>I will manage the ARs and APs and bank balances for you for 1/2
> >>>>>>>>>cost.  I will bounce all the business differences back to you,
> >>>>>>>>>
> >since
> >
> >>>>>>>>>you're the only one who can resolve them anyway.
> >>>>>>>>>
> >>>>>>>>>Q.  Ok.   Deal.
> >>>>>>>>>
> >>>>>>>>>A.  Ok then why don't you let the computers connect, and do it
> >>>>>>>>>for nothing?  You realize, in the long run, I'm going to be
> >>>>>>>>>
> >charging
> >
> >>>>>>>>>you money for operating a robot software I got from ebXML
> >>>>>>>>>open source?    sheesh...
> >>>>>>>>>
> >>>>>>>>>Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
> >>>>>>>>>International Accounting Services, LLC  www.gldialtone.com
> >>>>>>>>>425-827-3107  AR/AP everywhere  www.arapxml.net
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>----------------------------------------------------------------
> >>>>>>>>>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>
> >>>>>>>
> >>>>>>>
> >>>>>>--
> >>>>>>Michael C. Rawlins, Rawlins EC Consulting
> >>>>>>www.rawlinsecconsulting.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>----------------------------------------------------------------
> >>>>>>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>
> >>>>>>
> >>>>--
> >>>>Michael C. Rawlins, Rawlins EC Consulting
> >>>>www.rawlinsecconsulting.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>----------------------------------------------------------------
> >>>>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>
> >>>>
> >>>
> >>--
> >>Michael C. Rawlins, Rawlins EC Consulting
> >>www.rawlinsecconsulting.com
> >>
> >>
> >>
> >>
> >
> >
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> www.rawlinsecconsulting.com
>
>
>
>
>
> ----------------------------------------------------------------
> 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>
>