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 meetingWednesday 31st August
From: Tim McGrath <>
To:
Date: Tue, 13 Sep 2005 21:03:31 +0800
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.
