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: "Tim McGrath" <>
Date: Tue, 13 Sep 2005 17:13:50 +0200









Tim,
I 
read, that UBL has different structures as you can see from the screen 
dumps, except there is an academic level. 
Second, I added an example (see thze word file) with 
CCTS extension of a BIE Party for the Seller, where the name is SellerNew_ 
Party. Details. This is to show how an extension mechanism could work, 
especially if there was a CC layer.
In 
case, CCTS is a modeling methodology, people will ask how to reuse objects. 
Example: There are 15 typical contacts, which I want to use in many different 
places. Thus I want to define them just once and reuse it. The HOW to do this 
belongs to a 'rule set' (maybe called ontology? I do not know) and shall be a 
guidance for users, how to customize the models. The criteria (and no redundancy 
is one of them) need to be defined, when a BBIE goes into the 'core' level, 
e.g. Party. Details, and when it goes into a 'Seller_ Party. Details' and when 
it is a customization issue, where the user will do it.
The 
same with Account Identifier. UBL implements redundancy in the standard by 
defining Buyer Assigned_ Account. Identifier and Seller Assigned_ Account. 
Identifier as independent BBIE both for seller and buyer. This will be even more 
difficult, if the same approach applies for coded stuff with restrictions on a 
DataType code list.
 
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.