AW: 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: AW: AW: [ubl] clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August




From: "Michael Dill" <>
To: <>
Date: Wed, 14 Sep 2005 19:22:47 +0200










> UBL follows the 
third.

  
  Tim, 
  may I assume that there is no specific 
  document, where this is stated. Correct?  
  I did not know that this third way is an official UBL policy. Such an 
  important data model design decision must be documented, as well as others 
  (see my last email re this issue).
   
  CEFACT does not have this 
  either, even if it is better experienced in 
  using standardization procedures 
   
  But such a methodology and 
  design document is needed for UBL and all other 
  profiles of CCTS. And this need is independent from whether or not UBL becomes 
  a part of CEFACT or at least a co-operative separate standardization 
  organization.
   
  Agreed?  Your thoughts?
   
  regards.
  Michael
   
  
    -----Urspr�ngliche Nachricht-----
Von: Tim McGrath 
    [mailto:]
Gesendet: Dienstag, 13. 
    September 2005 15:04
An: 
Cc: 'Michael 
    Dill'; 
Betreff: Re: AW: [ubl] 
    clarification [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st 
    August

i must be missing something but you seem to imply 
    that UBL has separate structures for Party, Buyer Party and Seller 
    Party.  It does not.

i assume you agree that sometimes a role 
    played a party requires it have supplementary information known about it. 
    and that at the application level someone, somewhere is going to have to 
    recognize that a Buyer Party isn't the same as a Seller Party.  so 
    whatever we do needs to identify these differences, the only point at issue 
    is how we do that.

i only know of three ways of designing this:
1. 
    have three seperate structures that happen to have components of the same 
    name and no re-use of any structures,
2. have one structure encompassing 
    all components for any role a party may play, then making each role a subset 
    of that structure, (called subtractive refinement)
3. have one structure 
    encompassing all common components for any role a party may play, then 
    making each role an extension of that structure (called core plus 
    contextualization)

EDI standards tended to follow the second option, 
    UBL follows the third. 

Sylvia Webb wrote:

      
      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.