SV: [ubl] Payment Means cardinality in Order Response

["Peter Borresen" <PLB@itst.dk>]

The same thing should apply for OrderResponse and OrderChange

/Peter

-----Oprindelig meddelelse-----
Fra: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sendt: 28. juni 2007 01:57
Til: stephen.green@systml.co.uk
Cc: UBL TC
Emne: Re: [ubl] Payment Means cardinality in Order Response


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'.



stephen.green@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
>
>
>
>
>
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 
> 269.9.10/873 - Release Date: 26/06/2007 11:54 PM
>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath