RFC: Constraints on Cash accounts

[Bill Gribble]

On Wed, 2001-12-05 at 07:39, Conrad Canterford wrote:
> 2. If the (decimal) amount entered is not an exact multiple, it silently 
> rounds to the nearest exact multiple. I'm not convinced this should 
> *ever* be correct behaviour, and it definitely is not the behaviour I'd 
> expect in the case I'm proposing a solution for - I'm expecting a 
> warning of some sort, not a silent guess as to what I might have meant. 

I would expect that the warning would come when you try to commit the
transaction.  It won't be balanced, because one split will be rounded to
the nearest $0.05 and the other won't.  Does this not happen?

> For a start, we'd be guessing that "round-to-nearest" is the correct 
> behaviour and this needn't be the case for all currencies.

What do you mean?   This isn't a financial rule, it's a data-entry
rule.  i.e. if you enter a cash transaction in th amount of $1.06,
that's a typographical error, because no such transaction could have
occurred.  There aren't any per-currency rules about what to do; it's
just heuristic.  I tend to agree with you that a warning would be nice.

However, IMO this isn't a serious enough problem to merit the changes
that would require. We would be adding needless complexity to the
register and engine to catch a rather unusual class of data-entry error.
Leaving the default settings for your cash accounts doesn't prevent you
from entering correct information, and you'll just have to catch entry
errors in the same way you catch other entry errors: reconciliation
against another source of information. 

b.g.