RE: [ubl-dev] looking for practical examples

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

Yes, you will need to add rules, workflow and perhaps data stores and
documents. A full-blown inventory system involves a lot of process
complexity, so the relevant UBL documents are a "starter kit." 

With this "starter kit," you begin with a set of transactions and supporting
data and metadata standards that work. Many inventory management system
development teams exhaust themselves and their budgets on database design,
debates over metadata and data coding, system housekeeping functions and UI
matters etc. before getting very far with transactions. 

To see if this starter kit supplies the information needed to make the
system go, one can step through the functional requirements to determine if
1) the outgoing transactions can be built with data derived from other
documents, and 2) if incoming documents can be checked against outgoing
documents for consistency with expectations. 

For example, every inventory management system has to order and receive
replenishment. You will probably find that a UBL order can be generated by
pulling data from a predecessor UBL quote, from a consumption/stock level
query against prior "in" and "out" transactions, and from human user input.
Similarly, supplier dispatch advices can be checked against orders (e.g., if
the order was for ten, the advice should be for no more than ten).

The major gaps will come with respect to the internal dynamics of inventory
management as well as to supply master data.

For the most part, UBL has no sense of a transaction as a work in progress.
For example, if the inventory system generates a quote automatically based
on consumption, perhaps some supervisor has to OK it via keyboard entry
before it is released. Whether you create work in progress queues or create
intermediate documents is a design choice. Unless there is some existing
workflow/approval system to call, it might be necessary to build one.

UBL transactions call for exiguous master data - e.g., people's names and
contact information, ship-to address, etc. OASIS cis is an emerging standard
that could be used, but in any case you might have to build something if
there is no suitable data source to be called.

UBL transactions will deliver hazard code information, but again it cannot
route the acids to one side of the warehouse and the bases to the other
side, etc. Things that require forklift assistance may need to be routed to
a specific receiving site - again this sort of functionality would need to
be built or bought.

In creating new processes and documents to fill gaps, you can reuse many of
the same components used in standard UBL documents, which is where the
"custom" creation processes come into play.

Currency is not a problem if the UBL transactions themselves constitute the
database. The transaction currency is identified, and it is what it is. Note
that many inventory management systems with conventional data base systems
get wrapped around the compliance axle by trying to express all transaction
in, say, US dollars even though in reality several currencies were used.
Based on UBL transaction-level "truth," a query can re-express prices in
Euros or US dollars based on some compliant prescribed exchange rate and
date/time group.

Security, privacy, etc are of great interest today. One of the problems with
typical data base design is that it "unifies" and normalizes the separate
transactions. What I have described leaves the separate transactions
separate and entirely non-normalized, so writing security and access filters
becomes far easier (far easier is not necessarily synonymous with easy).


					Fulton Wilcox
					Colts Neck Solutions LLC













-----Original Message-----
From: Alexander Whillas [mailto:whillas@gmail.com] 
Sent: Friday, February 13, 2009 7:16 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>:

> As to whether standards can keep up with requirements, for most users they
> are far ahead.

If this is the case, why do I have to invent an Inventory document,
and its looking more like I have to.

There is another option that XML opens up and that is XSLTs to convert
one format into another. If I go with UBL, I have to:

1. Comprehend the 1500+ elements of UBL
2. Create XSD for the Inventory document
3. Implement

Where as if I create an ad-hoc XML inventory document I eliminate step
1 and speed up step 2 and in future if I need to interface with UBL
systems I (or who ever) writes an XSL Transformation.

Can you see how step 1 here is a disincentive to the developer with a
limited time/budget?

> 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.

Actually, how does UBL handle multi-currency pricing? I was looking at
Catalogue and the only mention of pricing is in

Catalogue
    CalalogueLine
        Item
            RequiredItemLocationQuantity?!?
                Price

Is there an attribute here somewhere that defines currency?

regards

alex

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