RE: [ubl-comment] Question about PaymentMeansType

[Andrew Chilcott <andrew.chilcott@stpsolutions.com>]

I believe that the PaymentMeansType element is required in the Order
Schema to provide for cases where 'Cash with Order' is the agreed method
of payment for the transaction. In such a case Michael is right in
saying that credit/debit/charge or any other type of payments need to be
catered for.

The PaymentMeansType element will probably be used infrequently in an
order  scenario and belongs primarily in the Remittance Advice that will
no doubt be a future UBL schema. Such a Remittance Schema will use many
of the elements created for the order and the invoice.

I can certainly think of situations where the paying party may be
different from the ordering party and I think that this is better dealt
with as a party role rather than trying to use the PaymentMeansType.

With regard to Patrick's point 

"....if I want to order something electronically from a supplier, and
bill my company's account with that supplier, there is no financial
institution
involved, since no currency is moving at the time of the transaction. Is
PaymentMeans appropriate for this type of transaction?"

Surely this is also dealt with as a party role (and within the party
element there are must be sufficient identifier elements). Patrick would
act the Buyer role and the company would act the InvoiceTo role.

I have already suggested that Jon Bosak gets in contact with BASDA
(www.basda.org) which has published a purchase order schema - it's
available for download from the site. In the BASDA schema there are
different party roles and a settlement element that includes card
details.

andrew.chilcott@stpsolutions.com
3rd Floor, Peek House, 20 Eastcheap, London EC3M 1EB
Tel:  +44 20 7929 3156
Fax:	+44 20 7626 3684
Mob:	+44 7775 564166 

-----Original Message-----
From: Michael Adcock [mailto:Michael.Adcock@apacs.org.uk] 
Sent: 16 July 2002 09:46
To: ubl-comment@lists.oasis-open.org; pgarvey@talaris.com
Cc: csmith@talaris.com
Subject: Re: [ubl-comment] Question about PaymentMeansType

I've an answer which raises more questions, so the list will see this
reply and I'm inviting all constructive comments!

There's a modification 'in the pipeline' about the aggregate
AccountDetails to change it to be FinancialAccountDetails which takes it
one step further away from your requirement, although there is no actual
implication of money changing hands at the Point of Transaction. In the
purchase order this would simply be saying "I'll pay from this bank
account", and payment would then be 'pulled' by the seller if Direct
Debit had been arranged or 'pushed' by the buyer making a payment order
to their bank.

I believe that we also need a CreditAccountDetails aggregate for the
kind of 'charge to a company's credit account with another company'
process that you mention. Could everyone who reads this think about what
pieces of information would be needed at the ordering stage in this
CreditAccountDetails aggregate? Bear in mind that this would really only
occur when there was an established and on-going business relationship
between seller and buyer, so I think it would be minimal information. 

I think the place where the CreditAccountDetails aggregate would be
used is in PaymentMeans as an alternative to the other accounts and
credit card info. (This also raises the point that we need a mechanism
for showing, for example, 'choice of one of these'.)

This does raise some further thoughts in my mind, which others should
please comment on.
Is the between-parties 'credit account' always with the Seller? Could
it be with an independent non-financial third party (possible banking
regulation issues here)? Could it be with a party related to, but not
precisely the same party as the Seller, for example if the seller is a
subsidiary company but the credit account is with the main company? If
so we would need to identify the party with whom the credit account was
held, as well as identifying the credit account.

And I suspect there is another situation lurking here. In the aggregate
DeliveryTerms, we currently have PaymentMethodId to allow an indication
of how carriage/transport/delivery is paid for. I suspect that we might
need to be able to associate PaymentMeans with this, in order to specify
fully how carriage/transport/delivery is paid for!

I look forward to comments...

Mike Adcock

Mike Adcock
Standards & Security Unit
APACS - Association for Payment Clearing Services
Mercury House, Triton Court
14 Finsbury Square
London EC2A 1LQ
Tel: +44 (0) 20 7711 6318
Fax: +44 (0) 20 7711 6299
e-mail: michael.adcock@apacs.org.uk

>>> Patrick Garvey <pgarvey@talaris.com> 16/07/02 00:37:00 >>>
Hello. I have a question about the intended use of the
PaymentMeansType, and, by extension, the AccountType. Is it designed
specifically for describing payments in which actual amounts of money
change hands from a payer to a payee? Or can it be used by a payer to
bill a credit account with a provider? In which case no money actually
changes hands until some settlement at a later date (end of the month,
etc.). 

The reason I ask this is that the PayeeAccount element contained inside
PaymentMeansType requires a FinancialInstitutionIdentifier. But if I
want to order something electronically from a supplier, and bill my
company's account with that supplier, there is no financial institution
involved, since no currency is moving at the time of the transaction. Is
PaymentMeans appropriate for this type of transaction?

Thanks

Patrick

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


**********************************************************************
The opinions expressed are those of the individual and not the company.
  Internet communications are not secure and therefore APACS does not  
     accept legal responsibility for the contents of this message.
  If the reader of this message is not the intended recipient, or the
employee responsible for delivering this communication to the intended
recipient, you are hereby notified that any disclosure, distribution or
   copying of this communication is strictly prohibited.  If you have
 received this communication in error, please notify us immediately by
          telephone to arrange for its return.  Thank you.
**********************************************************************

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>