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

[Tim McGrath <tim.mcgrath@documentengineeringservices.com>]

i want to thank Fulton for his excellent description of the UBL value 
proposition. 

I might add that no-one is claiming UBL has the perfect model (either 
too complex or not sophisticated enough!) but if we can avoid people 
reinventing new structures for the same purposes then we will have moved 
a step closer to effective information sharing.

PS. speaking of re-use I hope it is OK to re-use some of your words in 
future UBL public presentations?

Fulton Wilcox wrote:
> 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 
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>   
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+61 893352228
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard