[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] A 'Lite' Profile for UBL
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]