[ubl-lcsc] [QATeam]Normalized Components enter into QA

[Stig Korsgaard <STK@Finansraadet.dk>]

Hey Marion,

I miss having got the final solution to some of the comments I sent to
earlier versions.

The outstanding issues from my perspective are:

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.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.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.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.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 A Merry Christmas and Happy New Year to you all!

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