Re: [ubl-dev] A 'Lite' Profile for UBL

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

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