RE: [ubl-comment] Question about PaymentMeansType

["Probert, Sue" <Sue.Probert@commerceone.com>]

Title: RE: [ubl-comment] Question about PaymentMeansType

Hi Mike et al

Not sure that I can help much but my experience tells me that ten years ago when the first UN/EDIFACT transport messages were designed they did include the option to include payment mode/means information in a 'transport order' or shipping instructions as it now more often called. However, for many years the structure of this document type has dropped this option so I presume that it is no longer required in practice. It is certainly true that the message implementation rules developed by D4/ITIGG (the UN/EDIFACT International Transport Implementation Guidelines Group) does not include this option. The focus of ITIGG's work is largely rail, road and maritime transportation so it may still be required in the parcel carriage or air cargo transport arenas?

However, the UN/EDIFACT order certainly still contains this option but as separate implementation rules are usually set by different industry communities it is difficult to ascertain whether this is actually used between buyer and seller with regards to freight charges.

I guess that my D4 colleagues would know this much better than I and as I am meeting with some of them next week to work further on their BP modelling and core components projects, I will raise the question there.

Perhaps someonje from the UN/CEFACT trade groups can elucidate further?

regards

Sue

Sue Probert
Senior Director, Document Standards
Commerce One
Tel: +44 17534 830000
email: sue.probert@commerceone.com

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