FW: FW: [ubl-dev] looking for practical examples

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

Alexander,

Let's take this discussion back to your original inquiry.

First, you asked if could use UBL as a basis for your prospective inventory
system.

The answer to your question was that no, UBL 2.0 cannot literally be used as
an inventory system, because UBL 2.0 is a set of interoperability
transactions that serve to connect and, in a narrowly specified way,
synchronize multiple systems. A customer's newly-created purchase order in
system A becomes a supplier's sales order in system B, with no human
intervention to do the order import.

On the other hand, I suggested that if you are building a greenfield
inventory system you could get a head start by selectively reusing the
intellectual property (essentially spec freeware) embedded in UBL and in
doing so future-proof your system and database design in terms of
interoperability. An inventory system exhibits both a customer and a
supplier personality, so ideally it is supply chain aware in both roles. 

You looked at the UBL components and pronounced UBL to be too complicated,
but without relating your "too complex" judgment to inventory systems
processes and database requirements. It is not the creation of UBL that
introduced complication, but the reverse. UBL necessarily "imported" some of
the inherent process and content complexities of the supply chain as well as
country-to-country, company-to-company and system-to-system data diversity. 

At the lower end of UBL complexity, consider how UBL envelopes "price" at
the order line item. 

<cac:Price>
  <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> 
  <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> 
</cac:Price>

The enveloping identifies the price itself, specifies the currency in
accordance with global standards, identifies unit code in accordance with
global standards, and of course supplies the number of units. When this
order is imported into the supplier's internal systems, these data fields
all play a role in achieving company-to-company "interlock," - exact
alignment between the customer's and the suppliers understanding of the
transaction, with no human intervention in the data exchange.

You of course could build an inventory system that handles and stores price
"simpler" than this and uses units of measure of your own making, but you
would be sacrificing interoperability and perhaps business functionality.
Instead, I suggest emulating UBL data standards (and those global codesets
that it uses) rather than, for example, just creating a price "column."
  
At the other end of the complexity spectrum, consider the UBL specification
for "Self Billed Invoice," a snippet of which follows below. The full spec
for the Self-Billed Invoice" transaction runs on for 938 lines, and it
certainly is complicated.

Almost every manager running an inventory function wants to (or more likely
has been told to want to) do "self-billing," (also known as pay on receipt),
but almost none of them have the systems, information, and information
quality levels to do so effectively. Indeed, the gap between "wish" and
capability has been so great that inventory managers have required suppliers
to create and transmit non-invoice invoices so that companies can do
"self-invoicing" by echoing back the data even though they and their systems
lack self-billing capability. Being able to implement the self-invoicing
function potentially is a source of competitive advantage.

If you want your inventory system to supports self-billing, the UBL
specification can be a guide as to what the "right stuff" is to support that
function. Especially, it indicates what payload data needs to be sourced
from the internal inventory system functionality to populate the
transaction. 

If you do not need the self-invoicing functionality transaction, then the
fact that the UBL transaction is complicated is moot.

Indeed, the overall process of using UBL is, one hopes, subtractive. That
is, users pick through UBL transactions and components to select which are
relevant to them (and supportable by their systems and data) and discard the
rest. However, although UBL may be large and complicated, even those who
discard a majority of the transactions and components will want something
added, so what today looks large and complicated will inevitably grow.


					Fulton Wilcox
					Colts Neck Solutions LLC

<xsd:element ref="cac:InvoicePeriod" minOccurs="0" maxOccurs="unbounded">
- <xsd:annotation>
- <xsd:documentation>
- <ccts:Component>
  <ccts:ComponentType>ASBIE</ccts:ComponentType> 
  <ccts:DictionaryEntryName>Self Billed Invoice. Invoice_ Period.
Period</ccts:DictionaryEntryName> 
  <ccts:Definition>An association to period(s) to which the Self Billed
Invoice applies.</ccts:Definition> 
  <ccts:Cardinality>0..n</ccts:Cardinality> 
  <ccts:ObjectClass>Self Billed Invoice</ccts:ObjectClass> 
  <ccts:PropertyTermQualifier>Invoice</ccts:PropertyTermQualifier> 
  <ccts:PropertyTerm>Period</ccts:PropertyTerm> 
  <ccts:AssociatedObjectClass>Period</ccts:AssociatedObjectClass> 
  </ccts:Component>
  </xsd:documentation>
  </xsd:annotation>
  </xsd:element>

http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/maindoc/UBL-SelfBilledInvoice-
2.0.xsd