Summary: The init() interface appears in the consolidated IDL Specifications portion
of the document, but does not appear and is not documented or discussed in
section 2.3.8.

resolved by Currency 2 RTF

Summary: Propose the addition of the following interface(s):

void setDateRange(in CBO::Dtime beginDateTime,
in CBO::Dtime endDateTime) – Sets the window in
time over which the ExchangeRate instance is valid.
CBO::Dtime getStartDate() – Returns the date and time at which
the ExchangeRate took effect.
CBO::Dtime getEndDate() – Returns the date and time at which the
ExchangeRate is no longer valid.

Will also need an appropriate exception to throw when the date
range is attempted to be set and beginDateTime >= endDateTime. Do
not think that the beginDateTime should be allowed to be equal to
the endDateTime as that then means that the ExchangeRate is valid
for zero seconds.

resolved by Currency 2 RTF

Summary: The createExchangeRate() and getExchangeRate() interfaces accept arguments
sourceCurrencyMnemonic and targetCurrencyMnemonic. There is no mention in
the document regarding how the component should react (e.g. throw an
exception) if the passed arguments are the same mnemonic.

closed issue, resolved by Currency 2 RTF

Summary: Currency create(
in wstring name,
in wstring fractionName,
in wstring mnemonic,
in short numericCode,
in wstring symbol,
in wstring fractionSymbol,
in short ratioOfFractionToWhole,
in wstring description,
in CBO::DTime introductionDate,
in CBO::DTime expirationDate,
in boolean isISO,
in wstring ISOVersion,
in StringCollection locales)

resolved by Currency 2 RTF

Summary: getStateIdentifier() implies an accessor which it is not. Change name of
the interface to issueStateIdentifier().

resolved by Currency 2 RTF

Summary: Use of CosObjectIdentity::IdentifiableObject as the interface for a
stateIdentifier. There is a particularly concerning paragraph in v1.0 of
the Relationship Service regarding the interface: “The value of this
attribute [readonly attribute ObjectIdentifier constant_random_id] is not
guaranteed to be unique; that is, another identifiable object can return
the same value. However, if objects return different identifiers, clients
can determine that two identifiable objects are not identical”.

closed, no changes

Summary: In general the decision needs to be made as to whether a given
stateIdentifier is used to indicate the boundaries of a session or a simple
configuration, as it currently seems to attempt to support both. Whichever
direction is chosen, all of the interfaces that accept a stateIdentifier as
an argument should be revisited to ensure that the intent of the interface
is still properly supported. e.g. Should the currency component still offer
a “connectionless” interface to its consumers?

closed, no action taken

Summary: Can conversionFactor represent a value <= 0.0? I would think not. An
exception should be thrown if the conversion factor is attempted to be set
with a Ddecimal that represents a value <= 0.0
The beginDateTime must be < endDateTime in the init() call correct? Throw
an exception if this is not the case.
The source and target currency mnemonics cannot be the same in the init()
call correct? Throw an exception if they are.

Closed, no change. This issue is fixed by Issue 2393

Summary: Add the boolean valid(in CosObjectIdentifier::IdentifiableObject
stateIdentifier) interface. This must be included so that each interface
that accepts a stateIdentifier can do validity checking against it before
servicing the request.

closed issue, resolved by Currency 2 RTF

Summary: addCurrency() will raise an exception “if the currency already exists in
the CurrencyBook …”. There is no mention of what elements of a currency are
required to determine if one “already exists”. What
needs to be fully
detailed are those Currency elements which must be used to determine
uniqueness. e.g. mnemonic, numeric code, etc.

closed, resolved by Currency 2 RTF

Summary: areEquivalent() “determines whether the two passed-in Currency objects
contain the same elements”. Again, what needs to be fully detailed are
those Currency elements which must be to determine uniqueness. e.g.
mnemonic, numeric code, etc.

closed, resolved by Currency 2 RTF

Summary: Issue Description: Missing details on preconditions on the
ExchangeRateValue interface as a whole

resolved by Currency 2 RTF

Summary: The getCurrency() method name lends the consumer to believe that it is
simply an accessor method, which it is not. It is a searching method.
Change the method name to retrieveCurrency() or something that indicates
searching semantics.

closed issue, resolved by Currency 2 RTF

Summary: There is no description of isCurrentlyActive() and when/why it would return
true vs. false. Since it is described in the same area as the
introduction/expiration date, does it simply perform a check to see if the
current system time falls between the introduction and expiration
date/times?

closed , resolved by Currency 2 RTF

Summary: The init() interface appears in the consolidated IDL Specifications portion
of the document, but does not appear and is not documented or discussed in
section 2.3.7.

resolved by Currency 2 RTF

Summary: Issue Description: There is no mechanism to create Money instances via a
factory/type manager method.

resolved by Currency 2 RTF, close

Summary: There is no descriptive text stating why an FbcException would be raised
when calling init(), [gs]etCurrencyMnemonic(), or [gs]etValue().

resolved by Currency 2 RTF

: Need explanation that the ISO locale and it's associated format data will be provided by the vendor supplying the implementation.

resolved by Currency 2 RTF

Summary: Issue Description: Change name of CBO::DAmountOfTime interface to
CBO::AmountOfTime

:AmountOfTime

Summary: The value types in FbcCurrency (Currency, Money and ExchangeRate) need
state added to them as defined by Objects By Value.

resolved by Currency 2 RTF

Need clarification on formatting in MoneyFormatter. Can literal text be added to the formatting string, or is it strictly pattern based? If literal text cannot be added, add text to indicate the formatting string must contain only pattern characters.

Fixed in issue 2409

Summary: Clarify legal values for the MoneyFormatter format strings

resolved by Currency 2 RTF

Summary: The removeExchangeRate() interface may be too heavy handed. Modify
the semantics of this interface to support making an exchange rate
instance unsuitable for use (e.g. inactive). In this way, the exchange rate
instance would still be known to the component, but could no longer be used
in computations. It could however be extracted for reporting purposes, etc.
Would need interface accommodations though to indicate the extraction of
exchange rates that are “inactive”.

Not an issue

Summary: The behavior of the insertExchangeRate() interface should be modified.
Since ExchangeRates will now have a window in time over which they are
effective, the behavior needs to address what happens when an exchange rate
is attempted to be inserted that overlaps (in time) an existing exchange
rate. i.e. Suppose an exchange rate exists in the system for a certain rate
type, source currency mnemonic, target currency mnemonic, and is effective
from 12:00 15 July 1998 until 12:30 15 July 1998. Now suppose we attempt to
insert an exchange rate for the same rate type, source/target currency
mnemonics and is effective from 11:45 15 July 1998 until 12:15 15 July
1998. How does the insertExchangeRate() interface react in this case, or in
any other case where the exchange rate to be inserted has an effective
window in time that in whole or in part overlaps existing exchange rate
data?

resolved by Currency 2 RTF

Summary: There is no mechanism to modify what the negative prefix is, in a formatted
string. You can modify what the placeholder for the negative prefix is, but
not the actual prefix. This then means that "-" is to be used in every
locale. I would bet that we should support changing that character ... much
like we allow changing the radix character or the grouping character.
Hence, [gs]etNegativePrefixSymbol() above.

resolved by Currency 2 RTF

Summary: Need to indicate that an exception will be thrown if setFormattingString()
is called with formattingString being an empty string or one containing
white space only.

resolved by Currency 2 RTF

Summary: It appears that setFormatByLocale() and setFormattingString() override each
other, but the supporting text for each does not support this conclusion.
If setFormatByLocale() is executed, and then a call to
getFormattingString() is executed, a format specification for the given
locale should be returned correct? If a call to setFormattingString() is
then executed (which would change the format specification for the given
state identifier from the locale based specification previously),
getFormattingString() then returns the format specification just assigned
correct? The supporting text needs to address this behavior.

resolved by Currency 2 RTF

Summary: Interface changes for MoneyFormatter pattern handling

resolved by Currency 2 RTF

Summary: Fix typo to setPatternMnemonicSymbol()

resolved by Currency 2 RTF

Summary: Propose the following interface change(s):
short getInternalPrecision(in
CosObjectIdentity::IdentifiableObject stateIdentifier)
void setInternalPrecision(in
CosObjectIdentity::IdentifiableObject stateIdentifier,
short precision) – See example of use of this in the
MoneyCalculator Interface section.

Already resolved in a previous issue (2271)

Summary: Clarify on comparison methods of the calculator that no rounding etc. would
take place before the comparison, it would be the raw numbers in each
money instance that is compared.

resolved by Currency 2 RTF

Summary: Clarify how the ‘#’ is used in the money formatter – i.e. if the digit is
zero and doesn’t contribute to the value, 0 will not show.

resolved by Currency 2 RTF

Summary: Propose the following interface changes:
ExchangeRate createExchangeRate(
in wstring rateTypeId,
in wstring sourceCurrencyMnemonic,
in wstring targetCurrencyMnemonic,
in CBO::Ddecimal conversionFactor,
in CBO::Dtime beginDateTime,
in CBO::Dtime endDateTime)

Close, no action

Summary: Issue Description: What are the legal short precision values which can be
presented to setInternalPrecision()? Should it be limited to values >= 0?

resolved by Currency 2 RTF

Summary: The addExchangeRate() method name could connote mathematical summation.
Change the method name to insertExchangeRate().

resolved by Currency 2 RTF

Summary: In Fbc: Need the ability to have date based exchange rates and for the
manager to manage date based exchange rates.

• Since we need to start accounting for dates for exchange of currencies
  and also for doing multi-currency money calculations, it would be nice to
  add settings on the ExchangeRateManager that is state based that allows for
  client configuration.

resolved by Currency 2RTF

Summary: RoundingType.ROUND_DOWN – The textual description needs to be far more
explicit and/or include examples for both positive and negative numbers.
Round toward zero? Is the rounding digit truly ignored? e.g. Let the
internal precision be two.

resolved in Currency 2 RTF

Summary: .A Currency implementation should probably provide default values on behalf
of a given valid stateIdentifier (i.e. MoneyCalculator.roundingType,
MoneyCalculator.roundingDigit, MoneyCalculator.conversionType,
MoneyCalculator.internalPrecision, MoneyFormatter.radixSymbol,
MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol,
MoneyFormatter.inputMultiplier, MoneyFormatter.outputDivisor, locale,
etc.). The standard should state that a vendor’s responsibility is to
provide defaults, but leave the choice of the actual default values to the
vendor. An interface allowing state to be set back to defaults should be
considered.

resolve dis Currency 2 RTF

Summary: Need to add some additional enumerations to the ExceptionType enumeration.
Some of the suggestions are the following : INVALID_VALUE,
INVALID_STATE_IDENTIFIER, INVALID_DATE_RANGE, INVALID_CONVERSION_FACTOR,
INVALID_STRING (when a provided string is empty or contains only white
space), UNINITIALIZED_DATA, DATE_RANGE_FRAGMENTATION (when adding an
exchange rate whose effective window in time would fragment existing
exchange rates), INVALID_MULTIPLIER, INVALID_DIVISOR, STATE_IDS_EXHAUSTED.
(Our implementation plan is such that INVALID_ROUNDING_DIGIT,
INVALID_MULTIPLIER, etc. should really be discarded in favor of using
INVALID_VALUE. Where an explicit value has already been specified in the
submission (e.g. INVALID_ROUNDING_DIGIT) we will use it but hope for our
recommendation to be heeded. For exception types that are necessary but
were not included in the adopted submission, we will add our own (e.g.
INVALID_STATE_IDENTIFIER, INVALID_VALUE) and use whenever necessary.

resolved in Currency 2 RTF, closed

Summary: Propose the following interface change(s):
void init(
in wstring name,
in wstring fractionName,
in wstring mnemonic,
in short numericCode,
in wstring symbol,
in wstring fractionSymbol,
in short ratioOfFractionToWhole,
in wstring description,
in CBO::DTime introductionDate,
in CBO::DTime expirationDate,
in boolean isISO,
in wstring ISOVersion,
in StringCollection locales)
raises(FbcException); - Note in this signature that
scaleFactor, isExternalOutputShowingFractions, and
isInternalOutputShowingFractions have been deleted.

resolved in Currency 2 RTF, closed

Summary: The specification should state very explicitly how the subsystems/entry
points (i.e. StateIdManager, CurrencyBook, ExchangeRateManager,
MoneyFormatter, MoneyCalculator) locate each other if multiple vendor
implementations (e.g. StateIdManager and MoneyFormatter implementation from
one vendor and the remaining from another) can work with each other. If the
intention though is to support homogeneous implementations only (i.e. A
vendor solution supports all subsystems/entry points and only works with
its one implementation) this needs to be called out in the specification
instead.

No action taken, this has always been viewed as a component.

Summary: Can the wstring argument(s) to setMnemonic(), setName(), setFractionName(),
setSymbol(), setFractionSymbol(), or init() be empty strings or strings
containing only white space? Acceptable arguments need to be discussed.

resolved by Currency 2 RTF, closed

Summary: Missing details on preconditions on the Currency
interface as a whole

closed issue, resolved by Currency 2 RTF

Summary: Typos in the section that describes setRatioOfFractionToWhole(). The second
sentence should be “The ratio for United States Dollars is one hundred
pennies to one dollar, which is 100. In cases where there is no minor part
of a currency (e.g. Yen), this method should return a value of 1.”

resolved by Currency 2 RTF, close

Summary: Can the short numericCode presented to init() and setNumericCode() be <= 0?
What are its legal values?
Can the short ratioOfFractionToWhole provided to init() and
setRatioOfFractionToWhole() be <= 1? What are acceptable values?
Can the point in time represented by introductionDate be >= expirationDate
in init() and setExpirationDate()/setIntroductionDate()?

close issue, resolved by Currency 2 RTF

Summary: The init() method appears in the consolidated IDL Specifications portion of
the standard, but does not appear and is not documented or discussed in
section 2.3.6.

closed issue, resolved by Currency 2 RTF

Summary: Need exceptions for stateId indicating that one was never created from the
StateIdManager for all methods that take stateId.

resolved is Currency 2 RTF, closed

Summary: Change double to short for internal precision

resolved in Currency 2 RTF

Summary: Add idl and text to describe the getAllExchangeRates method

resolved in Currency 2 RTF

Summary: Add text for formatter that the format string will be used for parsing.
Clarify the formatting string and how it is used.
This way the parser routine will use: M##,###.00 to help it parse: RUR10,00
This also means the radix character was set to: "," and the grouping symbol was set to: "."
Show an example to distinguish between what the pattern gives you and what the actually settings of the characters give you.

resolved in Currency 2 RTF

Summary: Change text description of behavior of ROUND_FLOOR and ROUND_CEILING. The descriptions are mixed between the two.

Change text in spec describing the correct behaviour for the rounding rules

Summary: Clarify on comparison methods of the calculator that no rounding etc. would take place before the
comparison, it would be the raw numbers in each money instance that is compared.

Already fixed in issue # 2415

Summary: Need more clarification on how the "#" is used in the money formatter -
i.e. if the digit is zero and doesn"t contribute to the value, 0 will not show.

resolved and closed in Currency 2 RTF