101 Reasons not to pay an invoice - My ebXML consultant can'tunderstand your document

[David Lyon <djlyon@one.net.au>]

William,

I'll add this one to my list of 101 reasons not to pay an Invoice.

> And what did he mean by "rate"?  Actually I had no idea, but since he
> omitted "unit price," I made another assumption that "rate" was a
> synonym of "unit price."  Was the tax a rate or an amount?  Since he
> didn't explicitly say rate, I made another assumption.  Can I always
> expect the quantity * unit price + tax = amount, or are there some other
> assumptions and tricks?  Was Lyon's "description" really a product name,
> as I assumed?  What were his "comments"? I didn't say yesterday, but I
> assumed that it must've been an extended product description, even
> though it could just as easily have been shipping and handling
> instructions!
>
> This is a lot of assumptions to make, and just for a simple invoice line
> item.  The only way to be sure we're talking about the same things is
> for David to do a better job of documenting, or for me to call him up,
> where we both lose all solution scalability if we have to do that with
> each and every trading partner.

Sounds like a serious problem. Would some new spectacles help ?


David Lyon



----- Original Message -----
From: William J. Kammerer <wkammerer@foresightcorp.com>
To: ebXML Core <ebxml-core@lists.ebxml.org>
Sent: Thursday, May 03, 2001 4:53 AM
Subject: Re: What do people really expect from ebXML? - Whatever it is,it
better be easier than EDI


> David Powell would have us believe  "..... it is a quick and easy thing
> for an XML coder to map the names they use onto the names offered by
> their trading partner.."
>
> Well, David, if it were that "quick and easy," then nobody would've
> complained about EDI - why, it's just a matter mapping this field to
> that field!  Surely it can't be a matter of the asterisks and other
> delimiters that makes EDI hard, because a mapper insulates you from
> those petty details.
>
> I think my example for David Lyon yesterday regarding OBI's simple
> purchase order illustrates the problem:  How do you know which of my
> names is the same as his names?  I had to make assumptions, which I
> glossed over, when "mapping" Lyon's simple invoice line item: what did
> he mean by "code" - I guessed that it was the vendor part no., but by no
> means am I sure of that.
>
> And what did he mean by "rate"?  Actually I had no idea, but since he
> omitted "unit price," I made another assumption that "rate" was a
> synonym of "unit price."  Was the tax a rate or an amount?  Since he
> didn't explicitly say rate, I made another assumption.  Can I always
> expect the quantity * unit price + tax = amount, or are there some other
> assumptions and tricks?  Was Lyon's "description" really a product name,
> as I assumed?  What were his "comments"? I didn't say yesterday, but I
> assumed that it must've been an extended product description, even
> though it could just as easily have been shipping and handling
> instructions!
>
> This is a lot of assumptions to make, and just for a simple invoice line
> item.  The only way to be sure we're talking about the same things is
> for David to do a better job of documenting, or for me to call him up,
> where we both lose all solution scalability if we have to do that with
> each and every trading partner.
>
> Sue Probert's business about "fixing semantic anchors" with UUIDs, or
> some other artifact like normalized labels from the BSR or BSI/BEACON,
> is necessary so I can be sure Lyon's "description" is the same as my
> "product name."  EDI solves much, but not most, of the problem simply by
> having rigid names and dictionaries and code qualifiers: had I never
> seen the OBI documentation, I still would've have properly interpreted
> an OBI  PO instance with no ambiguity.   The same is not true if David
> Lyon had sent me an instance document containing his line item "tags" -
> at least not without making the assumptions I did.
>
> If the document were any more complicated [than a simple invoice line
> item], with only loose tag names like those provided by Lyon, then I'm
> very confident in saying I'd much rather have a big putrescent pile o'
> EDI land on my lap: at least I might have a fighting chance of
> interpreting its meaning without having to go back and forth with the
> sender.
>
> Listen folks:  whatever we come up with had better be a darn sight
> easier than EDI - and merely "readable" tags just ain't going to cut it.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>