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: Re: [ubl-lcsc] Re: Question on decisions from Montreal




Stig Korsgaard wrote:
Thanks guys for this clarification.

Let me add a few things. For the Payment Channel Code as Tim is describing,
we are ok. That just works fine the way it is now. 
good news

For Payment ID though there still seems to be some misunderstandings. First
of all the PaymentID is essential for automatic reconciliation in the ERP
systems. For that purpose it covers the full invoice and cannot be left to
be retrieved for every line item. It is also not only a national Danish
problem but something that is widely used across the world. 

Even more the PaymentID is not related to what the payments is made for "the
purpose of the payment" it is more a unique reference assigned by the
creditor to refer to the payment transaction. But only in some cases it is
either the creditors id of the payor (customer) or a AccountID. More often
it is specific generated for the invoice alone as one out of many (over
time) for the same customer and therefore the general ID does not work for
reconciliation.

Maybe the misunderstanding arises from the name which could also be
creditors reference!

SWIFT usage guideline says: the initiating party should provide this
reference the structured remittance info, to enable reconciliation by the
creditor upon receipt of the cash.

Does this help?
  
Yes it does.

After our meeting on Tuesday we concluded that what this element referred to is normaly satisfied by the combination of the Seller's BuyerAssignedAccountID (creditor reference) and the ID of the Invoice (transaction reference).  

Furthermore, within the scope of UBL's current document set, to establish a separate ID for this function could result in mis-use and confusion by potentially having two different identifiers for the same thing.  

If additional IDs are required for different business transactions (e.g. remittance advices), these would be candidates for contextualized extension of UBL for that purpose.

I hope this clarifies the UBL position.  Thanks again for your patience.


  

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 



-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk]
Sent: 23. oktober 2003 13:46
To: STK@Finansraadet.dk; tmcgrath@portcomm.com.au
Cc: ubl-lcsc@lists.oasis-open.org
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]