RE: AW: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: AW: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August




From: "Sylvia Webb" <>
To: "'Tim McGrath'" <>,"'Michael Dill'" <>
Date: Tue, 13 Sep 2005 00:28:31 -0700









Tim,
 
Please provide a list of the commercially 
available ERP packages in the low and mid range that support your design 
recommendations for Parties, Buyer, and Seller without customization. UBL 
implementers world wide will need this information.  

 
Regardless of any of our preferences or wishes, all 
of  the widely available or popular ERP and accounting products that I 
see, design software to support a finite set of structures for each 
function that they decide to support, including, those specified by standards 
like UBL.  They look at the similarities for all customer requirements and 
select those structures that allow maximum reuse with a minimum amount of 
programming.  The most robust software products permit users to customize 
structures. These also tend to be the most expensive products available serving 
the smallest number of implementers.  Even companies that have customizable 
software are challenged with which custom enhancements have the highest 
priority.  
 
With the large number of software products that do not 
support the flexibility that we're requiring for the procurement documents, the 
growing trend for companies to use commercially available software instead of 
doing in-house development, I'm afraid that the Universal Business Language has 
good potential to become the Exclusive Business Language with similar cost 
barriers to implement that EDI has today. 

 
Regards,
Sylvia


From: Tim McGrath 
[mailto:]
Sent: Monday, September 12, 2005 
7:19 PM
To: Michael Dill
Cc: 

Subject: Re: AW: [ubl] clarification [ubl] 
Minutes for Europe/Asia TC meeting Wednesday 31st August


I guess we agree to disagree.  But if you want some background 
to re-use of patterns then you might find Martin Fowler's article listed below 
of interest.

http://martinfowler.com/apsupp/roles.pdf

Michael 
Dill wrote:


  
  Tim,
  I 
  hope that you will be able to explain the opinion to the real world, that 
  there is one party structure in UBL only! I assume that the real world 
  considers most of the role extensions as part of the party. details. But let's 
  see, what will happen.
  btw: 
  the more I look at the library(ies), the more I feel, it will be at least 
  extremely difficult to maintain, understand and reuse 
  this.
  regards
  Michael
  
    -----Urspr�ngliche Nachricht-----
Von: Tim McGrath [mailto:]
Gesendet: 
    Donnerstag, 8. September 2005 08:42
An: 
Cc: 'Michael 
    Dill'; 
Betreff: 
    Re: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 
    31st August

my point to michael was that UBL 1.0 does 
    not have "multiple structures for party" - we have only one structure for 
    party. when a party plays the role of Seller we have additional properties. 
    But that is not a new definition for party.  It is an extension of the 
    existing definition.  it seems a logical way to do extensions but i am 
    happy to see an alternative proposal.

or, are you suggesting that we 
    can only restrict structures (such as ABIEs) and not extend 
    them?

Sylvia Webb wrote:

      
      Tim, you said "the backward compatibility is 
      only broken at a syntactic level (except in one case of Allowance Charge. 
      CurrencyCode).  we are desperately trying to keep 2.0 as semantically 
      compatible with 1.0 as we can.  that means unless we find 1.0 is 
      broken (as in the case mentioned) we would be very reluctant to change 
      existing structures."
       
      I did not notice 
      these multiple structures for party when 1.0 was developed. My 
      preliminary research shows that mostly high-end ERP packages support 
      the use of multiple structures for party. I can name 5 popular ERP 
      software packages in the U.S. for small to medium size (revenues >$10 
      million < $100 million) companies that only support one structure for 
      party. If you need multiple structures, you must create them yourself, 
      and, they can only be restrictions of the base party.  There are 3 
      well known accounting packages for companies with revenues of less than 
      $10 million that include modules for sales and purchasing that do not 
      support any changes if you need to define or use multiple 
      structures for party.  Buyer and Seller are universally required 
      for all businesses of all sizes that are involved in commerce and 
      trade.  
       
      I agree we need 
      to meet the needs of the existing structures defined in 1.0. I think we 
      also need to find a way to do it that supports the widest possible 
      user community.  The number of 1.0 implementations is low because the 
      standard is in its infancy. Now is the time to recognize the limitations 
      potential UBL users might have with multiple party 
      structures and change it when the user community is small, not 
      after such a change will impact a much larger user audience because 
      the standard is more mature.    
       
      Regards,
      Sylvia
      
      
      From: Tim McGrath [mailto:]
Sent: Wednesday, September 07, 2005 6:00 PM
To: 
      Michael Dill
Cc: 
Subject: 
      Re: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 
      31st August

my apologies i thought i had sent this but 
      it got held up in my drafts folder :-[ 
      

just so we dont lose track of this, I will reference 
      your email and the original minutes in the minutes of yesterday's call.

Michael Dill wrote:
  Tim,
obviously I was not able to describe clear enough, what my concerns are.
1. Here is the clarification for point b)
Tim minuted, that there are some concerns about the definition. In case, I
said this, then I apologize: I meant the structure mismatch between the
three existing parties. He argued, and I do not agree, that not to change
this is necessary to maintain compatibility. When it became clear that there
will be no minor version 1.1 but a major version 2.0, a number of backward
compatibility was broken anyway.