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

[david.lyon@computergrid.net]

Stephen,

> > 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.

This is how larger businesses tend to perceive these issues, especially for
those with the money to do things themselves.

But your opinion is still valid, and should be the provailing one.

It's true, there is no reason why everybusiness shouldn't be able
to accept a UBL invoice at some point in the future. I think you
are ontrack with your thinking here.

David

Quoting Stephen Green <stephen_green@bristol-city.gov.uk>:

> > 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
> 
> 
> 
> 
> 




-------------------------------------------------------