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

[David RR Webber <david@drrw.info>]

Folks,

A quick look at an OAGi BOD compared to a UBL PO for example - speaks volumes
here.  The PO BOD is developed for those big-endian ERP systems - and yes - UBL
is already 'BOD-lite'.  Yes you do need to understand those mapping rules and
be able to formalize them.  The CAM templates are designed to handle this -
"what happens when UBL hits the realworld?" - speed bump - and capture those
rules as XML scripts - and this is the key point - that are context driven.

This is not magic or patentable - its been going on for ever.  The world
consists of proprietary business rules - that spawn at virus like rates - that
happen because context localization is the constant driver.  Having mechanisms
that can mitigate this - to help enforce convergence - to provide people with a
formal way of implementing their own localization context - but in a perscribed
way - that does not break the overall interoperability model - is what this is
all about.

You have to make people have a behaviour adjustment - by providing a process
that can support that.  CAM I believe does that formalization.  It allows
people to start using registry services to create a community of interest (CoI)
and a shared vocabulary and knowledge set that is reusable.  While you have UBL
you have one part of the equation.  By adding XML scripts for business rules -
context management - and linkage to registry based vocabularies - then you can
start to build this.

Pedro - if you had access to this missing link for Portugese accounting CoI -
I'm sure your job would have been much easier!!

Cheers, DW.


Quoting Pedro Alves <pmalves@think.pt>:

> On Tue, Aug 24, 2004 at 12:55:03PM +0100, Stephen Green wrote:
> > Pedro
> > 
> > Thanks for these comments. The main question is: Did you cater for
> > integration with a back-office finance system? This is the main
> > factor UBL Lite addresses. Electronic messages have some value
> > even without back-office integration but it's debatable whether that
> > value would cover the cost of the XML development. What gives a good
> > business case is the elimination of rekeying into an existing finance
> system.
> > 
> > The point is that finance systems (finance packages) have limited ability
> > to process data once it is thrown at them. If my package can only receive
> > and, more importantly, store and send back out, discount at header level,
> > some clever progamming would be required of the integrator to handle
> > line level discount and there is a limit to how much of that clever
> programming
> > a software company can afford to put into its low-end products.
> > 
> > The most strightforward/common sense answer seems to many to be to
> > apply restricted functionality support to the message.
> > 
> > If you have a better answer I'd seriously think think about patenting it
> before
> > telling us! :-)  But we'd love to hear it anyway :-)
> > 
> > All the best
> > 
> > Stephen Green
> 
> 
>     Our product was developed to integrate with back-office finance
> systems, and currently we modules for Primavera, phc (portuguese ERPs), and
> will develop for navision, sage, etc in short term. 
> 
> 
>     From my experience, knowing at least a bit of how this ERPs work, I
> cannot think of a UML subset that satisfies all of them and would still
> work in other countries. 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.
> 
> 
>     And the input is different from project to project. We have modules for
> EDI, eBIS and xCBL. This "modules" are just stylesheets or classes that
> transform this languages to UBL.
> 
> 
>     Having every message transformed to UBL makes our package able to do
> more that just "store and send". We can apply simple (and not that simple)
> rules that can overcome the limitations of the back-end systems. 
> 
> 
>     I didn't patent it but it's done, so if you want it we can talk :)
> 
> 
>     Cumps
> 
>     Pedro
> 
> -- 
> Pedro Miguel G. Alves       pedro.alves@compta.pt
> COMPTA - Parceria e Tecnologia      www.compta.pt
> Tel:   +351 21 413 42 00  Av. José Gomes Ferreira
> Fax:   +351 21 413 12 20     nº 13 1495-139 ALGÉS
> 


http://drrw.net