RE: [ubl-dev] looking for practical examples

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

The UBL information domain is not "all," so clearly there are limits. On the
other hand, if your instance is inventory management, one can assemble an
inventory management system from UBL "parts" and supporting intellectual
property. For example:

An inventory system has a catalog (often referred to as a parts master), it
gets its stock from inbound transactions (purchase or release orders, ship
notices, receiving confirmation, etc.). It serves its customers via outbound
transactions (receiving customer orders, ships, confirmations, etc.). It
also experiences stock shrinkage and obsolete/overstock anomalies, all of
which can be embodied in "outbound" transactions (e.g., ships to a customer
named "thief," address unknown).  

Note that many data artifacts associated with an inventory system, such as
balance on hand, lead time, order point, etc. are better handled as compted
fields rather than stored fields. For example, balance on hand is the net of
ins minus outs. Auditors hate inventory systems that allow users to update a
stored field called balance on hand.

A system built around UBL transaction can have vastly greater capabilities
than the typical internal system, because it is essentially a communications
and interoperability vehicle built for eBusiness/supply chain processes

For example, an inventory replenishment process not only has to deal with
the internal catalog, but with suppliers' catalogs. In the typical inventory
system, supplier catalog data is usually handled by melding subsets of it
into the inventory system's own catalog, almost universally a profound weak
spot. If instead suppliers send UBL-compliant catalog updates which are
accessed natively, those can be used in the replenishment order creation
process to create "executable" orders: orders that do not "kick out" because
the product orders is obsolete, the price is wrong, etc. As this example
highlights, the power of XML is not that anyone can create an idiosyncratic
set of tags, but that a lot of players use the same tags within the same
conventions.

In doing what I describe above, in only rare instances will UBL not have
enough of the "right stuff." Instead, it will instead have too much, so the
system creation process would be mostly subtractive - e.g., the implementer
will ignore or default various feature and data.

As to whether standards can keep up with requirements, for most users they
are far ahead. In particular, many well-functioning inventory systems become
chronic problems because they were not "future-proofed" for success. For
example, the requirements spec did not even address multi-currency, the
system was hard-coded to the spec, but suddenly a requirement emerges to do
business in Canada or China.

The system I describe will need software "glue" to hold the process together
as well as some functionality not to my knowledge in UBL or other standard
eBusiness transactions (e.g., scheduling and routing capability to optimize
pick and putaway). On the other hand, it comes ready to interoperate.


						Regards,

						Fulton Wilcox
						Colts Neck Solutions LLC



-----Original Message-----
From: Alexander Whillas [mailto:whillas@gmail.com] 
Sent: Friday, February 13, 2009 1:07 PM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] looking for practical examples

2009/2/13 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:
> Internalizing external standards is an ambitious, but not unreasonable
> aspiration.

So what your suggesting is that ALL businesses base all their data
modelling (Databases, spreadsheets etc) on UBL process design so they
can fit within the UBL "truth"?

What if the standard doesn't fix the use case, such as in my instance?
What if business requirements change faster than standards?

I think standards should model real world needs not the real world
conform standards. XML is about defining a common language for systems
to communicate. The HTML 3.2 standard was a description of what was
going on with browsers, a description of what had evolved by itself. I
think the W3C helped to refine this and guide HTML in the right
direction with XHTML but new ideas have to come from industry and then
be refined by standards bodys.

my 2c

alex

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org