Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

Fulton

Yes, to me this all rings true. Lots can be done using UBL (or
equivalents if there are any) which goes beyond the current norm
(when the norm depends for its design on the need to overcome
problems eliminated using UBL between parties). The existence
of something ubiquitious creates a new set of possibilities quite
apart from the obvious ones UBL seeks immediately to solve. I
agree.

Many thanks for elaborating on these business drivers (good
points for a value proposition).

Best regards

- Steve

2009/2/13 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice