Re: [ubl] clarification [ubl] Minutes for Europe/Asia TC meetingWednesday 31st August

MHonArc v2.5.0b2 -->

















ubl message






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

--

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








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




From: Tim McGrath <>
To: 
Date: Thu, 08 Sep 2005 14:41:45 +0800










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.