[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-lcsc] Re: Question on decisions from Montreal
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. 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? 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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgrou p.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]