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] | [Elist Home]


Subject: [ubl-lcsc] Comments on Decision Items for meeting of Dec 3rd - Pl easeReview and comment


Dear Mike, Tim and all, 

Depending on the latest decisions and how complete we want to make the
spreadsheet I have the following comments related to Aggregates/BIES of
interest to finance including the use in their current context:

Address: 
Many systems do still not carry the ability to work with structured
addresses. Is there any way at all that we can accommodate this?

Exchange Rate:
In some countries (like DK) the Original Amount is needed here. REQUEST this
is added as a BIE (0..1).

By the way as a question for my clarification - why have for instance
Country been singled out as an ABIE while Amount has not?

And I do believe we should keep the Contract Reference as a BIE. On the
other hand the Exchange Rate ID is a puzzle to me also - if no business
needs established SUGGEST removal. I do not need it!

Financial Account: 
May in some countries (like in FR) needs a link to country also. SUGGEST
this added as an ASBIE (0..1) since this is the way it is done.

In the same way we need the link to the Financial Institution also - not
only the branch. SUGGEST this added as an ASBIE (0..1). 

Not all needs the Account Name and Type as mandatory information. REQUEST
changing both to (0..1)

On the other hand there may be more instances of ID like IBAN, BBAN,
Domestic, etc. REQUEST changes to (1..n)

By the way the ASBIE to the branch is not enough, the address of the branch
is also needed. I have forgotten so one question: Does the ASBIE link also
mean that the ABIE inherit the ASBIE own ASBIES? 

Financial Institution:
Also here there may be more ID types of the FI. REQUEST changes to (0..n) or
(1..n).

Also the ASBIE to the Branch is not always needed. REQUEST changes to (0..n)

Payment:
I do have some difficulties in keeping the overview here, but to make sure
here are some comments:

If we are linking this to structured remittance information there are
several types of Amounts that can be stated:
Referred Document Amount and Currency	 	 	 	The amount
and currency on a document referred to in the remittance section, which is
typically either the original amount due/payable, or the amount actually
remitted for the referenced document. 	
 	Due Payable Amount 	 	 	The amount specified is the
exact amount due or payable to the creditor.	
 	Discount Applied Amount	 	 	Indicates the amount is
resulting from the application of an agreed discount to the amount
due/payable to the creditor. 	
 	Remitted Amount	 	 	Indicates the amount specified is
the amount remitted for this referred document.	
 	Credit Note Amount	 	 	The amount specified for the
referred document is the amount of a credit note.	

I do not know how many of these are covered except from perhaps Due Payable.

As I see it also other areas of the structured remittance information is
missing, but I am not sure if it is the intention to state this here and if
so then where to put it - can you clarify this Mike?

Payment Means:
Should Payment Due Date be Payment Execution Date instead?

Payment Channel seems to be too simple. I think there at least is a need for
two further indications like Transfer Type like in RFT´s and Transfer Form.
also a free text possibility can be identified as needed.

Again  - Mike if I am wrong drop it - if not I have the information needed
ready to submit!.

Better later than never!

Best Regards
Stig Korsgaard
M.Sc.E., Standardisation Coordinator
Danish Bankers Association
Tel: +45 33 70 10 83
Cell: +45 21 21 82 34
Fax: +45 33 93 02 60
E-mail: stk@finansraadet.dk








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


Powered by eList eXpress LLC