[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-lcsc] [Fwd: Answers to answers on comments]
Subject: | Answers to answers on comments |
---|---|
Date: | Tue, 10 Dec 2002 14:00:53 +0100 |
From: | Stig Korsgaard <STK@Finansraadet.dk> |
To: | "'Michael Adcock'" <Michael.Adcock@apacs.org.uk>, mmartin@certivo.net, chris@cnelson.demon.co.uk, Stig Korsgaard <STK@Finansraadet.dk>, xmlgeek@gmi.net, tmcgrath@portcomm.com.au, dagmar.wachtmann@sap.com, gunther.stuhec@sap.com, michael.seubert@sap.com, Bill.Meadows@Sun.COM |
Hi Guys, Here is my feedback to your proposed answers! SK.1 Address Many systems do not have the ability to work with structured addresses. Is there any way we can accommodate this? Proposed answer: No, systems have to grow up some time! I cocnure with mike's sentiment - if we want interoperability we must be explicit. Agreed, but we all know this is unlikely to happen within few years even in Finance, so are we saying, that since this is the way it is, we do not care that our messages can´t be used in systems not having the ability to work with structured addresses. Even SWIFT has it still in newest models! Sk.2 Exchange Rate In some countries the Original Amount is needed here. Proposed answer: Surely not as part of the Exchange Rate. This is more likely to be done by associating an Exchange Rate (i.e. a conversion) with a pair of Amounts, Original and Converted. Do we have an 'amount' object? I think it would be useful (an extension of the CCT 'amount') If we do then your comment is what i would propose as well. Surely so! - But if you want to keep it as an ASBIE - I can live with it! On the other hand Tim may have a point! SK.3 Country Why has Country been singled out as an ABIE and not Amount? Proposed answer: Amount is already singled out to an extent as a Representation Type. So what Amount(s) would one single out as ABIEs. Country was singled out because it is often used by itself, as indeed a later question from Stig implies. Doesn't this contradict the answer to SK.2? Well amount can also be used alone. Nevertheless are we being compliant with the intend of the CCTS if we do what we do with country? - I think my problem is also that from a strangers point of view I could look as being inconsistent! SK.4 Contract Reference We should keep this as a BIE Proposed answer: The Foreign Exchange contract is just another kind of Contract, and so is an Object associated with ExchangeRate, not simply a BIE within Exchange Rate. I agree that our prefernce is to have association BIEs rather than basic BIE where possible. It creates a more flexible model to build structures off. Well ok if so deemed! SK.5 ExchangeRate The ExchangeRate ID is a puzzle to me. Proposed answer: Agreed to delete this. I agree with Mike's answer Fine SK.6 Financial Account May need a link to Country. Proposed answer: Agreed to have an association with Country. I agree with Mike's answer Fine SK.7 Financial Account May need a link to Financial Institution. Proposed answer: Why? It's always linked to a 'branch' even if the branch happens to be the Head Office Branch. I agree with Mike's answer So by that you mean that the FI will appear through the ASBIE to the branch which are linked to Account as an ASBIE? If so and it then still can appear - Fine with me! SK.8 Financial Account Not all need Account Name and Type. Proposed answer: Okay, change to 0..1 I agree with Mike's answer Fine SK.9 Financial Account Various Ids Proposed answer: An Account Id is the Account Id. All could be derived from the IBAN, in theory, although there are mutinous thoughts that the I stands for Impossible rather than International! Maybe we need multiples, yuk! Does this mean we have a situation like ItemIdentification and OrderItemIdentification? No matter the reason - yes this is needed! SK.10 Financial Account Does an ASBIE in an ABIE inherit the ASBIE's ASBIEs? Proposed answer: Yes! I agree with Mike's answer Good - thought so! SK.11 Financial Institution More ID types needed. Proposed answer: Why? One should be enough to identify it. What you put in as the identifier is the key. I agree with Mike's answer, this may be geeting too detailed Well yes and no. Yes if we do not care about the content in the tagging and the subsequent validation. No if we do and have the need for multiple ID´s and we do in some instances. So either increase the number of repetitions or make more ID´s! SK.12 Financial Institution Proposed answer: Some bank if it does not have any branches! I presume SK.12 is Stig's request for FI -> FIBranch to have 0..n cardinality. What is problematic is that if it has no branches we cannot have an account and it means we will never see the FI???? Maybe 1..n is OK with the default branch as the FI itself. I am not sure I can follow the answer here - but think I agree with Tim! SK.13 Payment Series of comments Proposed answer: The only reason that Payment appears in the model is to associate one or more payments with a Trade transaction from a trade perspective. In no way is this attempting, will attempt, or even intend, to model a complete payment. That is another business process and scenario that is outside the scope. I agree with Mike. When we say payment we means , 'record of payment' not the event itself. Maybe the definition could make this clearer. Fine - then this has to be very clear perhaps by actually linking the term Payment to the BP in question! - Otherwise people will get confused. SK.14 Payment Means Should Payment Due Date be Payment Execution Date? Proposed answer: No, Payment Due Date is trade parlance and is the date on which the Seller expects to be paid by the Buyer. When the payment is executed by the bank is to an extent irrelevant; the Seller wants his money on the day he expects it, and the Buyer has to trigger payment accordingly early! I agree with Mike (again !!!) Fine - anyway we need to clarify this. Because it is also used in Finance although as an equal synonym for Execution. SK.15 Payment Channel Seems to simple Proposed answer: EDIFACT over-engineered this with other pieces of info and people got confused so the same thing can be expressed in several different fields. If we can have a clear separation of the important bits of info, with clear definitions, then we could accommodate. Can we consider this another 80/20 situation where we have enough for the majority of cases? OK - But Finance will need further information not covered by this object for the time being - how we then will solve it can be left to that time, where we start discussion payments in Finance. Suggest again the limitation of the object due to the link to the BP is clarified. Best Regards and thanks 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
-- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC