OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] Re:


Fulton,

With due respect, your posting is very interesting, but completely off
the point of the issue at hand. The CCTS model is quite clear.  Either
UBL conforms to it or it doesn't, and either UBL wishes to harmonize
with UN/CEFACT Core Components or it doesn't.

Kind Regards,

Mark 
Mark Crawford 
SAP Standards Architect 
Office: 703 670-0920 
Mobile: 703 485-5232
---------------------------------------------------------- 
Chair: ISO 15000-5 ebXML Core Components 
Lead, UN/CEFACT Core Components Harmonization Project 
Vice Chair UN/CEFACT Applied Technologies Group 
Chair UN/CEFACT XML Syntax Working Group 

 

> -----Original Message-----
> From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com] 
> Sent: Monday, March 06, 2006 2:11 PM
> To: Crawford, Mark; swebb@gefeg.com
> Cc: ml@tritorr.com; ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] Re:
> 
> 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 
> 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]