Re: Question on decisions from Montreal

[Tim McGrath <tmcgrath@portcomm.com.au>]

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