ubl-lcsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: Question on decisions from Montreal
- From: Tim McGrath <tmcgrath@portcomm.com.au>
- To: Stig Korsgaard <STK@Finansraadet.dk>
- Date: Thu, 23 Oct 2003 14:09:45 +0800
This was brought up at Montreal and again a few weeks ago when we realised
a mistake in the model. I hope you will find that now we have associated
'Payment' to the 'Payment Means' it clarifies the situation.
The UBL Payment Means now has....
PaymentMeansTypeCode
DuePaymentDate
PaymentChannelCode (identifies the system through which the payment is processed,
using a standard codelist.)
CardAccount
PayerFinancialAccount
PayeeFinancialAccount
CreditAccount
Payment
ID (identifies the payment transaction that settles a debt. For
example, if the payment was by means of a cheque, then this ID would be the
cheque number.)
PaidAmount
ReceivedDate
We understood that Payment ChannelCode is what was meant by Instruction
Code (EDIFACT 4435 code)
However, the UBL Payment->ID is not what the eGov team meant by their
PaymentID (EDIFACT 1153 code). This is more like a reference to what the
payment was for. We have taken a different approach to EDIFACT on how to
do this. This is because UBL is based on hierarchical structures that are
easier to express in XML. The way to find out what a payment was for in
the UBL Invoice is to look to its parent structure for references. Each
UBL Invoice Line may contain one or more AllowanceCharges which in turn contain
the PaymentMeans. So for a given Invoice Line we can say what allowances
or charges are involved. The same Invoice Line may also contain a reference
to Items, Taxes, OrderLines, DespatchLines, ReceiptLines or Deliveries. These
tell us what the PayementMeans was for. UBL did not adopt the use of a code
set for this. We see the means of adding additional transaction references
as being achieved by extension of the schemas rather than extending code
lists. Hopefully UBL has captured to 80% of cases. But, if the Danish Bankers
required additional types of payment references they could extend their UBL
schemas to define these.
Stephen may have some further comments, but this was how i recalled it.
Stig Korsgaard wrote:
Hi both,
For the Montreal meeting the Danish part of the e-Gov TC had some comments
to the structure of our LCSC library and in particular the Payment Means
object.
In order to use the scenario in a simple invoice scenario in Denmark we
need
two
additional elements in the PaymentMeans object. These elements could be
added to
the PaymentMeans object by expanding the Core Component Type under the
rules
in
"Guidelines for a compatible customization of UBL schemas" (WD 5), or they
could
be added by including the two new elements in the PaymentMeans object in
the
UBL
Invoice. The information is necessary when payment is done by use of Joint
Payments Cards which is the default mean of payment in this scenario.
The two elements we need in PaymentMeans are:
* PaymentID (Identification of Payor/Payment for reconciliation of incoming
payments).
* InstructionCode/Code for transfer forms (Identification of type and
functionality of form).
I do remember we discussed that, but I must admit I have lost track of the
conclusions. Could either of you help me by referring the decision we took
on this? And also why we did not include it, because as far as I can see
it
is not included in releases!
I include the full set of comments here!
<<20030629 Danish eGov review of UBL 8.pdf>>
Best Regards
Stig Korsgaard
M.Sc.E Standardisation Manager
Tel: +45 3370 1083
Cell: +45 2121 8234
Mail: stk@finansraadet.dk
Danish Bankers Association
Amaliegade 7
DK-1256 Copenhagen K
Tel: 3370 1000
Fax: 3393 0260
mail@finansraadet.dk
www.finansraadet.dk
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]