[ubl-lcsc] [Fwd: Answers to answers on comments]

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

-------- Original Message --------

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