[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] looking for practical examples
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]