[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] A 'Lite' Profile for UBL
Stephen, ERP systems have selected OAGi BODs for this - not UBL-lite. This brings up a bigger issue. OAGi BODs contain different and extended information structures that may or may not map well to the UBL equivalence. Where there is a loss of information richness - that is obviously a problem. While trying to define a lowest common functional set is useful (aka EDI did this) - the loss of flexibility is what XML is supposed to be solving. So standing on the high ground and saying 'our stuff is better' - may be a honset feel-good factor - unfortunately the world works around business needs and business drivers. OAGi have learned to support this through their user extension areas in the transactions. However - this only partly ameloriates the problems - since the semantics are missing. This is the difference between raw data - and information. By augmenting the exchange with things like CAM templates and registry vocabularies - you can significantly enhanced the exchange - not just of raw data - but the intent, purpose and context to provide meaning and information. Thanks, DW > > ----- Original Message ----- > From: "Stephen Green" <stephen_green@bristol-city.gov.uk> > To: ">" <<ubl-dev@lists.oasis-open.org> > Sent: Tuesday, August 24, 2004 11:17 AM > Subject: Re: [ubl-dev] A 'Lite' Profile for UBL > > > > Our method is to develop a xml schema that has > > only the things we want to map and with a xsl make a transformations or > > build a class to work with the UBL message itself. The decision depends on > > how the ERP works. > > Mmm. Your solution seems to be to create a subset for each and every ERP. > > I hope that in this day and age we can do better than that. > > What happens when a user of one ERP wants to send a document to a user > of another? The idea is that electronic invoices, say, should be such that > my ERP > can send one to yours without me having to know what ERP you use, only that > your system can handle UBL Lite, say. Then if you change your system you > don't > have to ask or, eventually, even tell me about it. You can just register it > somewhere > that you can receive UBL Lite invoices and orders once your ERP adds > functionality > to support them or you can obtain a plug-in or ASP service which integrates > with > your application. This is, I believe, what we are trying to achieve (in a > similar way to > EDI but without the high costs). Maybe there is some way yet but I believe > it is doable. > > If a particular ERP has problems with the Lite profile, the profile should > be tailored > such that it minimises the investment required of that company (and passed > on to > its customers perhaps) to change its system a little or build in > adaptations. One way > to achieve this is to closely align with best practise such as that defined > by companies > like PWC and those which are generally acceptable in most countries. > Invoices and > orders have the advantage that they've been around so long and are so > prevalent > that everyone has a similar understanding of them and similar laws covering > them > - yes with a few, but not many discrepancies, which appear to be relatively > simple > to work around. Bigger problems are found in the other layers of the stack > such > as encryption requirements but as time goes on there may be rationalisation > of these > too. The technology is new perhaps but not the underlying message. > > All the best > > Steve > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]