RE: [ubl-dev] Re:

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

Mark Crawford,

Mark,

There are some situations in which a standards group "decides" for itself
what should pertain and others in which the group merely "discovers" what
logically and practically should pertain. 

The invoice header/invoice line construct, with an invoice having at least
one line is, I suggest, is more such a "discovery" rather than a "decision."
I also suggest that it more important to converge on a small set of options
that fit the mainstream discoveries rather than diffuse efforts across many
options.

The following points have to do with "discovery."

1. If you attended a convention of corporate Chief Financial Officers and
polled attendees as to what are the minimum and maximum number of lines an
invoice should have, I do not know what the CFOs would cite as a maximum,
but you can be sure the minimum would be 1, not 0. 

If you held a CFO "breakout group" to design the "perfect invoice," it would
resemble the UBL invoice in having line item detail (and in other respects).
That is particularly true if you asked them to design the perfect inbound
invoice - one that they have to pay.

2. If a small business CFO went to an office supply store and bought a set
of pre-printed business forms, invoices, POs, etc., the invoice would have
line item detail.

3. If you look at a major invoice-creating or invoice-consuming ERP, notably
including SAP, the logic of the process and data design is that there is
line item symmetry on both the sellside "order to cash" and "purchase to
pay" levels. 

Like everyone else enmeshed in legacy requirements and expectations, SAP has
of course implemented all sorts of ways of invoicing and applying non-line
item "fees." However, when one tries to "mate" two companies' SAP instances
in a trading relationship, it becomes evident that it is far better if both
have maintained line item purity across purchase to pay and order to cash
processes.

As I have noted in other contexts, a sad reflection of today's often useless
variants to invoices is the practice of a large buyer company (with a
sophisticated ERP) requiring employees of a selling company (with perhaps
the same ERP) to key invoice data into the buyer's system, because
electronic invoicing "doesn't work." Electronic invoicing of course "works,"
but often is defeated because both entities are captive to their respective
particularities and carryovers from long ago.

4. From a business exception handling perspective, having a uniform approach
is helpful. For example, every so often a "single line" invoice that was
issues as a zero-line invoice must be reissued with two line items. What
happens then - e.g., does the (new) second line become line item 1? Does the
re-issued version express the form "imputed" line item as line item 1 and
the new line item as line item 2?

5. If we turn to the imperatives of business intelligence, dashboards, etc.,
it is that data be held within well-ordered, easily understood granular
detail, with sales data or purchasing data often held at the invoice line
level. In de-normalizing data for analysis, it is far more likely that the
BI database designers will bring header information "down" to the invoice
line level than bring invoice line data "up" to header level. Creating
invoices with no line items forces the ETL process to make them up.

6. XML is fundamentally a hierarchical arrangement of metadata "tags" with
payload data interleaved, ideally suited to "header" followed by "detail."
On the other hand, the fundamental nature is not optimized for a "look here
first," but sometimes "look there" if you don't find it "here." Doing both
"here" and "there" runs across the grain rather than with the grain of XML.

7. If we look at life from a regulatory perspective, every "choice" needs to
be defended. Is the choice correctly framed as a rule? Is the rule correctly
applied to a given case? Is the decider (human or machine) sufficiently
authoritative, etc? Invoices are particularly touchy with respect to
taxation, business fraud, securities fraud, etc., so creating unneeded
choice creates more regulatory cost and risk.

8. If we look at the billions (may be trillions) of actual EDI and XML
invoices, a majority follow the header/invoice line construct. Indeed, an
EDI standards group in the early 1980's would not itself have designed an
invoice document that does not have an invoice line. As today, there was
pressure to adopt shortcuts and particularities which, for the most part,
created more cost of complexity than simplification.

Given the above "discoveries" (most pretty intuitive) for following fairly
narrowly defined standards, where do the exceptions come from?

Mixed in with today's single or multiple line item invoices (whether
electronic or paper) are millions of "no-line" invoices. Many have to do
with transactional add-ons and afterthoughts, of which shipping charges are
a good example. For example, the seller not only has to invoice the buyer,
say, 1,000 USD for the seller's widget, but 75 USD for the seller's
prepayment to the parcel shipping company to ship the widget to the buyer's
premises. 

I suggest that all of such situations are better and easily handled as line
items on invoices. A separate zero line item electronic invoice (please send
75 USD for shipping a widget) creates substantial business process and
business control issues and, often, will go into a buyer's exception
processing queue (sometimes, never to emerge). Note that in today's SOA
environment (and with respect to SAP Netweaver in particular), the
opportunity exists to do calls against the parcel shipper's system to pick
up shipping charges in time to meld them in with the main invoice.

The CFO who instinctively prefers that an invoice be structured as
header/line may in an earlier day have designed a business process such as
zero-line shipping invoices. Nevertheless, we are better off addressing the
CFO's "ideal" rather than backing into a standard that preserves
idiosyncratic variants.

How to attain convergence?

For better or worse, nobody needs UBL's permission or validation to create
and transmit "non-standard" invoices. Such invoices are sent as EDI
artifacts, as flat files, or as XML artifacts.  CFO's and others have plenty
of opportunity to preserve or proliferate particularities.

On the other hand, advancing the cause of particularities is not in my view
a mission of a standards group. If one asks, why did EDI "fail" or, at
least, substantially under-achieve original expectations, the answers
typically offered are "too complicated", "too expensive", etc. These answers
are almost all wrong with respect to "vanilla" transactions. The EDI great
chain of being: e.g., order to shipping advice to invoice to payment - is
not much more complicated than filling out the office supply house's
pre-printed forms encapsulating those same transactions.

Instead, it was and is the continued proliferation and carry-forward of
shortcuts and exceptions that has landed eBusiness invoicing on the
"vicious" rather than the virtuous side of Metcalf's Law. Robert Metcalf
observed that the "power of a network increases as the square of the number
of nodes" participating. We are certainly benefiting from the "virtuous"
effects of Metcalf's Law given wide use of Internet standards and other de
jure or de facto standards. A lot of eBusiness is conducted using Microsoft
Excel, merely because it has such a widespread and loyal user base.
Similarly, eBusiness needs to get to the "virtuous' side of Metcalf's Law
with wider adoption and a wider, loyal user base, not necessarily all that
expert. 

Unfortunately, exceptions create centrifugal forces that mask any unifying
"truth" on which we can independently converge. As a result, the "n squared"
aspect of Metcalf's law works against us rather than for us. For example,
given the amply supply of variants, getting 100,000 trading partners to
exchange invoices (and supporting upstream transactions) requires
implementers to address something approaching 100,000 squared variants -
and, by the way, not 100,000 squared minus one, because even a given
company's internal business unit to business unit charge backs typically
exhibits some exceptional transaction hairballs.

Therefore, standards needs to flow with what is "discovered" on a "just
complex enough" lean sort of basis. Adopting 1990 vintage exceptional
conventions, often to accommodate 1990 vintage technology and business
process limitations, serves the past, not the future. Discovering and
encapsulating the fundamentals in a "less is more" set of features is
advantageous to future adoption by a much wider constituency.



					Regards,


					Fulton Wilcox
					Colts Neck Solutions LLC



-----Original Message-----
From: Crawford, Mark [mailto:mark.crawford@sap.com] 
Sent: Monday, March 06, 2006 6:35 AM
To: swebb@gefeg.com
Cc: ml@tritorr.com; ubl-dev@lists.oasis-open.org
Subject: [ubl-dev] Re:

So this means that despite efforts to move ubl to cefact, and despite the
availability of approved core component that ubl could use as the basis for
developing their BIEs, UBL is refusing to do so. Very interesting and rather
disturbing.
--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: Sylvia Webb <swebb@gefeg.com>
To: Crawford, Mark <mark.crawford@sap.com>
CC: 'Mark Leitch' <ml@tritorr.com>; ubl-dev@lists.oasis-open.org
<ubl-dev@lists.oasis-open.org>
Sent: Mon Mar 06 02:16:04 2006

Mark,
 
Mark Leitch requested that I answer your question.
 
The answer is no. The Document. Details CC based on the Audited TBG17
library dated February 2006 is a ACC.  UBL does not use any CEFACT ACC's.
 
Regards,
Sylvia
____________________________________________________________________________
____________________________________________________________________________
_________________
 
----- Original Message ----- 
From: "Crawford, Mark" <mark.crawford@sap.com>
To: "Stephen Green" <stephen_green@seventhproject.co.uk>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Thursday, March 02, 2006 12:42 PM
Subject: RE: [ubl-dev] UBL 2.0 public review


Stephen,

In defining the AttachedDocument ABIE, did you use the approved CEFACT
Document. Details CC?

Kind Regards,

Mark