[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] looking for practical examples
Stephen, My point is to minimize "customizations" and even non-customized internal to external "translations" by 1) having companies/institutions make UBL generated transactions (e.g., inbound or outbound orders) a part of the internal database, and 2) by using the supporting building blocks and data standards to flesh out areas not covered by the relevant UBL transaction (e.g., perhaps internal approvals, accounting, etc.) The notion that eBusiness standards such as UBL are "external" is I believe a transitional rather than equilibrium stage in data and transaction management. As companies increase the proportion of transactions that flow via "eBusiness" (not necessarily using UBL although for discussion I'll assume so), the duplication of transactions approaches 100%. That is, for every internal "purchase order" created in the user company's internal system, there is a matching outbound UBL order built through translation and perhaps customization (not only UBL customization, but internal customization with calls to multiple internal systems - e.g., to pick up delivery mode and delivery window information for some ship-to location). On the other hand, if the company's internal systems creates, updates and reports on purchase orders that are in fact conformant UBL orders, the need for either translation or customization is reduced or eliminated. For example, if when the internal user specifies delivery constraints, the internal system collects, edits and updates that information within the context of a UBL order, the internally created order is native "UBL." For someone doing a "greenfield start" of an ERP (and people do such things, usually through scope creep), what I describe is becoming increasingly practical and desirable. Advances in technology are obviating a lot of performance issues, while making content integrity "king" as people no longer can inspect quality into the transactions. Nevertheless, few if any of those designing or extending internal systems even give a passing thought to internalizing external standards like UBL (CIS, etc.). For those whose internal systems are set in "concrete," a fallback is to use collections of inbound and outbound UBL transactions as BI (business intelligence) resources to be accessed directly by BI queries (e.g., if the data warehouse is virtual) or to be replicated into data warehouses. In effect, inbound and outbound UBL transactions represent transaction "truth," both in terms of authoritativeness and, often, completeness. In the lossy external to internal translation process, relevant "truth" may be discarded or corrupted through compression. For example, if needed to accommodate an internal system's database design/configuration, the translation process may compress UBL "RequestedDeliveryPeriod" start date/time and end date/time payload information into a single "no later than" date field. Consequently a BI query as to whether deliveries last month satisfied customer requirements will lack integrity, because although the query will return "late" delivery incidents down to day, it cannot assess the hour (having the express delivery driver leave the ordered laptop on the front steps at midnight on Friday will be shown as an "ontime" delivery). The query cannot detect "early" delivery at all, because both date and time were discarded. My organization did business with a major automobile company unit that could not do authoritative supplier on-time delivery performance analysis because they did not have access to "truth" as to when a purchase order or release order was dispatched even though their EDI engine had that information down to the minute. Internalizing external standards is an ambitious, but not unreasonable aspiration. Fulton Wilcox Colts Neck Solutions LLC <?xml version="1.0" encoding="UTF-8" ?> - <Order xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2 " xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParame ters-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponent s-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateCompo nents-2" xmlns:udt="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule :2" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2"> <cbc:UBLVersionID>2.0</cbc:UBLVersionID> <cbc:CustomizationID>urn:oasis:names:specification:ubl:xpath:Order-2.0:sbs-1 .0-draft</cbc:CustomizationID> <cbc:ProfileID>bpid:urn:oasis:names:draft:bpss:ubl-2-sbs-order-with-simple-r esponse-draft</cbc:ProfileID> <cbc:ID>AEG012345</cbc:ID> <cbc:SalesOrderID>CON0095678</cbc:SalesOrderID> <cbc:CopyIndicator>false</cbc:CopyIndicator> <cbc:UUID>6E09886B-DC6E-439F-82D1-7CCAC7F4E3B1</cbc:UUID> <cbc:IssueDate>2005-06-20</cbc:IssueDate> <cbc:Note>sample</cbc:Note> - <cac:BuyerCustomerParty> <cbc:CustomerAssignedAccountID>XFB01</cbc:CustomerAssignedAccountID> <cbc:SupplierAssignedAccountID>GT00978567</cbc:SupplierAssignedAccountID> - <cac:Party> - <cac:PartyName> <cbc:Name>IYT Corporation</cbc:Name> </cac:PartyName> - <cac:PostalAddress> <cbc:StreetName>Avon Way</cbc:StreetName> <cbc:BuildingName>Thereabouts</cbc:BuildingName> <cbc:BuildingNumber>56A</cbc:BuildingNumber> <cbc:CityName>Bridgtow</cbc:CityName> <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone> <cbc:CountrySubentity>Avon</cbc:CountrySubentity> - <cac:AddressLine> <cbc:Line>3rd Floor, Room 5</cbc:Line> </cac:AddressLine> - <cac:Country> <cbc:IdentificationCode>GB</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress> - <cac:PartyTaxScheme> <cbc:RegistrationName>Bridgtow District Council</cbc:RegistrationName> <cbc:CompanyID>12356478</cbc:CompanyID> <cbc:ExemptionReason>Local Authority</cbc:ExemptionReason> - <cac:TaxScheme> <cbc:ID>UK VAT</cbc:ID> <cbc:TaxTypeCode>VAT</cbc:TaxTypeCode> </cac:TaxScheme> </cac:PartyTaxScheme> - <cac:Contact> <cbc:Name>Mr Fred Churchill</cbc:Name> <cbc:Telephone>0127 2653214</cbc:Telephone> <cbc:Telefax>0127 2653215</cbc:Telefax> <cbc:ElectronicMail>fred@iytcorporation.gov.uk</cbc:ElectronicMail> </cac:Contact> </cac:Party> </cac:BuyerCustomerParty> - <cac:SellerSupplierParty> <cbc:CustomerAssignedAccountID>CO001</cbc:CustomerAssignedAccountID> - <cac:Party> - <cac:PartyName> <cbc:Name>Consortial</cbc:Name> </cac:PartyName> - <cac:PostalAddress> <cbc:StreetName>Busy Street</cbc:StreetName> <cbc:BuildingName>Thereabouts</cbc:BuildingName> <cbc:BuildingNumber>56A</cbc:BuildingNumber> <cbc:CityName>Farthing</cbc:CityName> <cbc:PostalZone>AA99 1BB</cbc:PostalZone> <cbc:CountrySubentity>Heremouthshire</cbc:CountrySubentity> - <cac:AddressLine> <cbc:Line>The Roundabout</cbc:Line> </cac:AddressLine> - <cac:Country> <cbc:IdentificationCode>GB</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress> - <cac:PartyTaxScheme> <cbc:RegistrationName>Farthing Purchasing Consortia</cbc:RegistrationName> <cbc:CompanyID>175 269 2355</cbc:CompanyID> <cbc:ExemptionReason>N/A</cbc:ExemptionReason> - <cac:TaxScheme> <cbc:ID>VAT</cbc:ID> <cbc:TaxTypeCode>VAT</cbc:TaxTypeCode> </cac:TaxScheme> </cac:PartyTaxScheme> - <cac:Contact> <cbc:Name>Mrs Bouquet</cbc:Name> <cbc:Telephone>0158 1233714</cbc:Telephone> <cbc:Telefax>0158 1233856</cbc:Telefax> <cbc:ElectronicMail>bouquet@fpconsortial.co.uk</cbc:ElectronicMail> </cac:Contact> </cac:Party> </cac:SellerSupplierParty> - <cac:OriginatorCustomerParty> - <cac:Party> - <cac:PartyName> <cbc:Name>The Terminus</cbc:Name> </cac:PartyName> - <cac:PostalAddress> <cbc:StreetName>Avon Way</cbc:StreetName> <cbc:BuildingName>Thereabouts</cbc:BuildingName> <cbc:BuildingNumber>56A</cbc:BuildingNumber> <cbc:CityName>Bridgtow</cbc:CityName> <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone> <cbc:CountrySubentity>Avon</cbc:CountrySubentity> - <cac:AddressLine> <cbc:Line>3rd Floor, Room 5</cbc:Line> </cac:AddressLine> - <cac:Country> <cbc:IdentificationCode>GB</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress> - <cac:PartyTaxScheme> <cbc:RegistrationName>Bridgtow District Council</cbc:RegistrationName> <cbc:CompanyID>12356478</cbc:CompanyID> <cbc:ExemptionReason>Local Authority</cbc:ExemptionReason> - <cac:TaxScheme> <cbc:ID>UK VAT</cbc:ID> <cbc:TaxTypeCode>VAT</cbc:TaxTypeCode> </cac:TaxScheme> </cac:PartyTaxScheme> - <cac:Contact> <cbc:Name>S Massiah</cbc:Name> <cbc:Telephone>0127 98876545</cbc:Telephone> <cbc:Telefax>0127 98876546</cbc:Telefax> <cbc:ElectronicMail>smassiah@the-email.co.uk</cbc:ElectronicMail> </cac:Contact> </cac:Party> </cac:OriginatorCustomerParty> - <cac:Delivery> - <cac:DeliveryAddress> <cbc:StreetName>Avon Way</cbc:StreetName> <cbc:BuildingName>Thereabouts</cbc:BuildingName> <cbc:BuildingNumber>56A</cbc:BuildingNumber> <cbc:CityName>Bridgtow</cbc:CityName> <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone> <cbc:CountrySubentity>Avon</cbc:CountrySubentity> - <cac:AddressLine> <cbc:Line>3rd Floor, Room 5</cbc:Line> </cac:AddressLine> - <cac:Country> <cbc:IdentificationCode>GB</cbc:IdentificationCode> </cac:Country> </cac:DeliveryAddress> - <cac:RequestedDeliveryPeriod> <cbc:StartDate>2005-06-29</cbc:StartDate> <cbc:StartTime>09:30:47.0Z</cbc:StartTime> <cbc:EndDate>2005-06-29</cbc:EndDate> <cbc:EndTime>09:30:47.0Z</cbc:EndTime> </cac:RequestedDeliveryPeriod> </cac:Delivery> - <cac:DeliveryTerms> <cbc:SpecialTerms>1% deduction for late delivery as per contract</cbc:SpecialTerms> </cac:DeliveryTerms> - <cac:TransactionConditions> <cbc:Description>order response required; payment is by BACS or by cheque</cbc:Description> </cac:TransactionConditions> - <cac:AnticipatedMonetaryTotal> <cbc:LineExtensionAmount currencyID="GBP">100.00</cbc:LineExtensionAmount> <cbc:PayableAmount currencyID="GBP">100.00</cbc:PayableAmount> </cac:AnticipatedMonetaryTotal> - <cac:OrderLine> <cbc:Note>this is an illustrative order line</cbc:Note> - <cac:LineItem> <cbc:ID>1</cbc:ID> <cbc:SalesOrderID>A</cbc:SalesOrderID> <cbc:LineStatusCode>NoStatus</cbc:LineStatusCode> <cbc:Quantity unitCode="KG">100</cbc:Quantity> <cbc:LineExtensionAmount currencyID="GBP">100.00</cbc:LineExtensionAmount> <cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount> - <cac:Price> <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> </cac:Price> - <cac:Item> <cbc:Description>Acme beeswax</cbc:Description> <cbc:Name>beeswax</cbc:Name> - <cac:BuyersItemIdentification> <cbc:ID>6578489</cbc:ID> </cac:BuyersItemIdentification> - <cac:SellersItemIdentification> <cbc:ID>17589683</cbc:ID> </cac:SellersItemIdentification> </cac:Item> </cac:LineItem> </cac:OrderLine> </Order> -----Original Message----- From: Stephen Green [mailto:stephengreenubl@gmail.com] Sent: Friday, February 13, 2009 2:52 AM To: fulton.wilcox@coltsnecksolutions.com Cc: G. Ken Holman; ubl-dev@lists.oasis-open.org Subject: Re: [ubl-dev] looking for practical examples Sorry Fulton I didn't see you email till after I'd written mine but it looks like there is consistency between them in seeking to cater for systems built for UBL being able to handle custom schemas. I'm thinking maybe SET provides one benchmark to ensure this. One SET use case if mapping between versions of UBL http://lists.oasis-open.org/archives/set/200902/threads.html#00000 I would think others are mapping between customisations or between customisations and standard UBL schemas or even between, say a customisation of UBL and GS1-XML which shares the implemen- ation of CCTS. This might require that the custom schemas implement CCTS too. It might also be helped if they implement an NDR (naming and design rules), perhaps an extension or adaptation of the UBL NDR, or one included in the customisation guidelines. A test that your/my concerns are met would be to try the SET tool which generates an ontology (OWL) from the schema. I don't yet know how this works and SET is not yet standard but if folk know of other such tools which might provide the use/test case for a customisation NDR I think they would be useful and necessary to keep the overall UBL design development ontrack to meet real world business requirements. Best regards - Steve 2009/2/13 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: > As perhaps exemplified by Ubercart, it may be useful to look through the > other end of the mapping/customization telescope to see whether people can > adapt their internal systems to UBL and related eBusiness standards. > Ubercart has no inventory management module, so adding one is something of a > fresh start. > > We are accustomed to dealing with large companies and governments with > internal systems that define "their way", and indeed "their way" is cast in > concrete because they cannot change their internal systems and data > standards. Mapping and customizing UBL is therefore needed to accommodate > "their way" and, one can hope, conceal the peculiarities of "their way" from > their trading partners. > > The opposite and in many ways more promising situation is when the trading > entity (or its software supplier) does not have a "their way" at all and may > be open to incorporating UBL and supporting standards into an unformed or > still malleable internal system. People are still "inventing" coding schemes > for, say, unit of measure, because they are not aware of the advantages of > using standards already on the shelf, especially those available at no cost. > Many of the opportunities are in venues far afield from big name supply > chain unstitutions, including Internet 2.0 and open source players. > > The question for the standards community is whether we can reach the people > who are preparing to pour concrete and get them to internalize standards > before they do the pour. In some situations, the opportunity might exist to > use native UBL documents as the internal "data base." > > The push for internal-external convergence rather than "mapping" has to come > from the external side, because of course internal parties have nothing on > the shelf designed to be used by many companies. > > > Fulton Wilcox > Colts Neck Solutions LLC > > > > -----Original Message----- > From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] > Sent: Thursday, February 12, 2009 5:53 PM > To: ubl-dev@lists.oasis-open.org > Subject: Re: [ubl-dev] looking for practical examples > > At 2009-02-10 19:13 +0000, Stephen Green wrote: >>1. Create a new document called, say, Inventory - with your own >>namespace for the document but import the common schemas so >>you can make it almost the same as the UBL Catalogue - just with >>a new InventoryLine, like Ken says, which adds StockQuantity or >>something like that (and maybe a few more things like that). There >>are a few things to make the writing of the schema (like Ken, I too >>strongly recommend keeping to a schema - testing the messages >>that they are valid by the schema - at design stage at least). You >>will want the extra InventoryLine and somewhere to put it in the set >>of schemas. Maybe Ken has an opinion on whether to put this >>aggregate in the document schema (I guess that breaks the NDR, >>Ken) or whether to create not just a custom document schema but >>a 'common' schema too: If the latter then maybe both a basic and >>an aggregates common schema? > > Precisely! The following is a diagram from our training material > that we delivered in Australia in January, and is now available as > part of the latest edition of our "Practical Universal Business > Language Deployment" book (published today!): > > http://www.CraneSoftwrights.com/sales/Crane-UBLProfile/#schemasy > > I'm proposing to the UBL TC that these diagrams be included in the > customization guidelines. > >>Those technical issues might seem overly detailed. > > But I think the approach is sound, which is why it is included in our > book and training material. > >> > And if you can join the TC, bring in your new documents, and find others > to >> > collaborate with in order to come up with flexible and useful >> configurations >> > of those new documents, they might end up becoming UBL documents! > > Which was the reasoning behind creating aggregate and basic schema > fragments analogous to those of UBL so that the business objects can > migrate into the common library if the UBL technical committee > chooses to effect. > > I hope this helps. > > . . . . . . . . . . . Ken > > -- > Upcoming hands-on XSLT, UBL & code list hands-on training classes: > Brussels, BE 2009-03; Prague, CZ 2009-03, http://www.xmlprague.cz > Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video > Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 > Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ > Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- 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]