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