Payment Means cardinality in Order Response

Can I consider this closed or are there still queries ?

Regards, Mark

 

Mark Leitch

Director - Tritorr Ltd

tel.:       +44 1932 821112

cell.:      +44 7881 822999

mail:      

skype:    wmarkle

site:       www.tritorr.com

 

Begin forwarded message:

From: Mark Leitch <>

Date: 28 June 2007 10:48:54 BDT

To: , Peter Borresen <>, Tim McGrath <>

Cc: UBL TC <>

Subject: Re: SV: [ubl] Payment Means cardinality in Order Response

 As far as I can see, there is only one UBL 2.0 document that has unbounded Payment Means and that is the Invoice itself; the other five documents that have Payment Means (Quotation, Order, Order Change, Order Response and Self Billed Invoice) all have 0..1 Payment Means.  Note: Payment Means is also in AllowanceCharge (0..n), Statement (0..1), StatementLine (0..1), Remittance Advice (0..1), Reminder (0..n), but not relevant to this conversation.

As far as I can remember, the unbounded Payment Means in Invoice was a Swedish requirement for situations where an Invoice could be settled via a bank or via the Giro system; it wasn't to facilitate multiple due dates.  I do have to say, however (and the NES customisation has proved this), having the due date only available in Payment Means is a real pain !  In NES we have to use a Payment Means Code "1" just to get access to the due date for the Invoice where the due date is not Payment Means specific.

"Traditionally" we have thought of the Quotation document as the carrier for punch-out (or round-trip) information; punch-out basically means that the information is brought back from a remote location (Supplier site) to populate a Requisition in the Customer domain from which an Order will be derived (following the appropriate internal approval processes).  I think Stephen is referring to a simple straightforward web Order which is a different thing.  Whether multiple due dates are required in this scenario is debatable as is the validity of the Order Response adopting the role of the Order, but what remains is the fact that Invoice is the only document in question that facilitates unbounded payment due dates rather than that's being the norm.

I don't know if that answers the question ... or if there was, in fact, a question.

Regards, M

 

Mark Leitch

Director - Tritorr Ltd

tel.:       +44 1932 821112

cell.:      +44 7881 822999

mail:      

skype:    wmarkle

site:       www.tritorr.com

 

On 28 Jun 2007, at 09:40, Peter Borresen wrote:

The same thing should apply for OrderResponse and OrderChange

/Peter

-----Oprindelig meddelelse-----

Fra: Tim McGrath [mailto:]

Sendt: 28. juni 2007 01:57

Til: 

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

 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