OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ubl-lcsc] Re: Question on decisions from Montreal


Stig and Tim

I got the impression from the Danish review submission that what they 
thought was lacking for PaymentID was covered now by what we have in
a combination of SellerParty.SellerAssignedAccountID and Invoice.ID

I think we asked and were waiting for more information though and I 
still couldn't say I'm clear about the details and use of
"InstructionCode/Code for transfer forms" for Payment Card payments.
I think we do need to look in more detail at PaymentMeansTypeCode and at 
PaymentChannelCode.

All the best

Steve


>>> Tim McGrath <tmcgrath@portcomm.com.au> 23/10/03 07:09:45 >>>
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]