RE: [ubl-dev] Mapping business model fields to UBL 2.0

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

Stephen,

 

By "atomic" transaction, what I mean is a naturally joined set of line items, order together. An order for a laptop might be a multi-line item transaction that includes a separate power supply, carrying case, etc. which may be distinct line items The subsequent transactions such as shipping advices or invoices would align with the "atomic" order.

 

The "bad" non-atomic transactions originate in various efforts to optimize essentially manual processes. For example, in the purchasing sphere or invoice processing sphere, almost universally the people who run those functions have been told (correctly) that the overhead cost per transaction is some high number (e.g., commonly an organization might estimate its administrative cost per purchase transaction to be 50 USD each), so make the number of transactions go down. People are rewarded for aggregating multiple requisitions into one purchase order, switching to one invoice for everything bought from a given vendor during the month, etc. They often are rewarded for adding information requirements that should be handled by their BI processes (e.g., incorporate year-to-date consumption information onto a given transaction). Even in the manual world, these transaction-reducing aggregations often add rather than reduce complexity, and the world if full of people trying to get authorization for paying an invoice even though a dozen or more people have to approve their particular subset of the complex invoice.

 

End-to-end mechanized processes have entirely different cost characteristics. A trading relationship may be somewhat costly to set up (one hopes not), but once set up and tested the per transaction cost goes down into pennies as long as the various transactions can be handled without human intervention. Doing a three way match (order to receiving to invoice match) if they are what I described as "atomic" and "atomic" in the same way (e.g., in my example, the laptop and associated widgets is ordered, received and invoiced at the same level of granularity).

 

My point was not that there be some bureaucratic mandate in favor of atomicity, but that people understand that electronically implemented trading relationships need to be optimized differently from manual processes.

 

 

                                                                                    Fulton Wilcox

                                                                                    Colts Neck Solutions LLC

 

 

 

 

 

 

 

 

 

 

 

 

---

From: Stephen Green [mailto:stephengreenubl@gmail.com]
Sent: Monday, July 13, 2009 12:48 PM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Mapping business model fields to UBL 2.0

 

As an aside, the obvious problem here seems to me that one cannot
really expect the other party to send atomic (which I take to mean
single-line) documents.