atom feed8 messages in org.oasis-open.lists.ublRe: [ubl] Payment Means cardinality i...
FromSent OnAttachments
step...@systml.co.ukJun 27, 2007 12:37 pm 
Tim McGrathJun 27, 2007 4:56 pm 
Peter BorresenJun 28, 2007 1:41 am 
John LarmouthJun 28, 2007 2:01 am 
Mark LeitchJun 28, 2007 2:48 am 
G. Ken HolmanJun 28, 2007 6:52 am 
John LarmouthJun 28, 2007 8:55 am 
Mark LeitchJul 11, 2007 2:28 am 
Subject:Re: [ubl] Payment Means cardinality in Order Response
From:Tim McGrath (tmcg@portcomm.com.au)
Date:Jun 27, 2007 4:56:26 pm
List:org.oasis-open.lists.ubl

If you are proposing changing the cardinality from 0..1 to 0..many then I would say this is backward compatible and could be a candidate for UBL 2.1.

An instance of of UBL 2.0 OrderResponse wold still be valid under 2.1 with the extended cardinality.

Have you added this to the issues list?

To view the issues list, the URL is:

http://www.eccnet.com/UniversalBusinessList/IssuesList.xml

To add a new issue the form is available at:

http://www.eccnet.com/UniversalBusinessLanguage/AddIssue.html

The login is 'ubl' and password is 'issues123'.

step@systml.co.uk wrote:

Greetings UBL TC

As pointed out to me by Luca Reginato in Italy, we have an inconsistency between the document types in that in most of them PaymentMeans has minimum occurance 0 and maximum occurance unbounded, which is great as PaymentDueDate can be automated even when there are multiple payment due dates by using multiple PaymentMeans occurances. So far so good. However it is quite a general requirement to use the OrderResponse document as a key document (usually calling it 'order confirmation' or 'order acknowledgement') as with what is called 'punch out' and similar common practises. In such cases the OrderResponse is the primary document from the seller (or seller's agent) and so it there is a strong requirement to include here the payment information such as a Payment Due Date or set of Payment Due Dates. The inconsistency is that in UBL 2.0, although the need for such payment requirement information is acknowledge by the inclusion of PaymentMeans, it is only, in the OrderResponse with the allowance of zero or one occurances (hence only a single payment due date at most).

I do accept that fixing this would be quite a challenge as it may involve a backwards compatibility issue. Maybe there is a way to fix it by creating a new ASBIE and ABIE which has multiple occurances and appending it to the Order Response. Otherwise it would seem implementers making primary use of the OrderResponse in this way have to 1. create their own extension which reduces the opportunities for interoperability or 2. use a document such as Invoice in situations where this is otherwise deemed as unnecessary (and therefore more expense is imposed which doesn't necessarily bring a proportional return on investment perhaps) or 3. do without the automation of the payment due dates and just use a note or description. I think 3. is unsatisfactory as it should be a major benefit of using UBL that payments can be fully automated as part of use of implementing electronic procurement with UBL.

Best regards

--Stephen Green

Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice