[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Fwd: [office-comment] Data Type Specification and
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2007-06-08 23:49:11
Message-ID: 13ed09c00706081649g77c0645fo7f0a2bf05b58915a () mail ! gmail ! com
[Download RAW message or body]

> That shouldn't be a problem if your computer has an Internet
> connection. KSpread could just poll xe.com,

Whatever method is used to convert currencies, I do not think it
should be chosen implicitly because the correct conversion rate may
depend on the specific application.  Often when I receive invoices for
example, the conversion rate from USD or EUR to GBP is a fixed value
specified ( I think ) by Customs and Excise.

For other spreadsheets I have worked with, the conversion rate will be
specific for each order, so adding the USD value from an order at the
start of the month and the USD value from the order at the end of the
month and performing a conversion to GBP will produce an invalid
result.

I agree with the basic concept, but I think that any form of implicit
conversion between currencies is risky - unless that conversion is
done using some fixed value in the spreadsheet.

I also see currency conversion errors in spreadsheets frequently.
Newer versions of Excel can spot inconsistant formulae and other
common mistakes which is useful, I would be surprised if that didn't
include any currency conversion checks - but it is still quite
primitive in that the produced warnings are easily overlooked.

Regards,
Robert.

On 08/06/07, André Somers <andre@familiesomers.nl> wrote:
> Hi,
>
> I think you are right actually. I think that a good way to handle this would
> be to indeed allow "joinings" for typed numbers with scalars (multiplication
> and devision and the like, at least). However, different currencies should
> be different types. A (set of) conversion functions could then convert one
> currency to the other. Using different functions would enable you to choose
> if you want to use the current rates from the internet, if you want to
> choose your rate yourself (from a cell or entering directly), retreive the
> current rate once on entering, using a fixed (know) exchante rate, etc.
> Whatever. I think this would be a correct way to approch it, and maintain
> flexibility as well.
>
> André
>
>
> ----- Original Message -----
> From: "Thomas Zander" <zander@kde.org>
> Sent: Friday, June 08, 2007 12:02 PM
> Subject: Re: Fwd: [office-comment] Data Type Specification and
> Conversionlikein FORTRESS
> On Friday 08 June 2007 11:35:43 André Somers wrote:
> > An issue might arise if you start mixing currencies though. Problem is
> > that they do not have a fixed exchange rate, so you can't just mix them
> > without telling what their exchange rate is. Worse, this rate varies in
> > time, and thus might just change within one sheet.
> > Still, the idea is interesting!
>
> I'd say that any addition of numbers that are not of the same type[1]
> (say, percentage and currency, or US currency and euros) should all
> generate a warning or even an error while typing the equation or running
> the sheet.
>
> In other words; doing currency conversion is something the sheet should
> not try to do automatically.
>
>
> 1) technical background requires me to say that numbers without explicit
> type should be able to be joined with anything. This allows you to
> convert from euro to US by multiplying it with a plain number which
> avoids problems in the above mentioned restrictions ;)
> --
> Thomas Zander
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]