OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]