Re: [ubl-comment] Question about PaymentMeansType

[Michael Adcock <Michael.Adcock@apacs.org.uk>]

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