[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] A 'Lite' Profile for UBL
Sorry When rather than say 'ERP systems' I should be saying finance software/packages (by which I mean those which by definition might benefit from a Lite profile if they had a business case for adoption of UBL - this could be because they wish to only have to support the Lite profile, initially at least, or because there are likely to be trading partners using apps which support the Lite profile). Steve >>> "David RR Webber" <david@drrw.info> 24/08/04 16:28:07 >>> 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]