On Fri, 07 Jul 2000, Randolph Fritz wrote:
> On Fri, Jul 07, 2000 at 01:51:35PM -0500, Richard Wackerbarth wrote:
> > Right. And the dry goods were either measured in units of (3 inches) or
> > greater or no effort was made to account for the individual amounts sold.
> >
> > Particularly in a business such as dry goods, the amount that you
> > actually receive does not match the amount for which you were charged.
> > The merchant has figured this waste into the price he charges.
>
> I just bought some velcro ribbon...trust me, the amount I actually
> received matches the amount I bought to within at most 1/4". If I was
> buying wide vellum from an art supply shop, it would be within 1/16".
And gold chain even closer.
So what? Each item has its own "smallest unit of measure" and there is some
approximation made when the larger inventory is partitioned into the portion
that you purchased and that which you did not.
> Yes, yes. However the receipt I have, which is the merchants's original
> transaction document, is written in yards. This merchant is measuring
> (rational numbers) rather than counting (cardinal numbers), and
> keeping track of cash at their register.
I don't think so. He measured to do the cutting, but counted for the sale.
Did you have the option of purchasing 1 1/2 yards? Probably. 1 1/8 yards?
Perhaps. 1 1/144 yards? I doubt it.
Just because we display "1 1/3 yards" doesn't mean that we cannot store the
transaction as "48 inches"
> One of the ways in which the widespread availability of computers
> transforms traditional bookkeeping practice is that jobs which were
> previously back office are now done in real time at the cash register.
> This, to me, suggests that gnucash might be more useful to these
> merchants if it accomodated the way the merchants do business, rather
> than requiring the merchant to do conversions into a traditional
> accounting form.
See above. Input and Output do not have to be in the same units as storage.
If I were building a cash register for the dry goods store, I would certainly
include keys for 1/2, 1/3, 3/4, etc. Or at least have some input convention
that allowed it.
> Why not? Seriously, if the big banks do it, does gnucash need to do
> more? Compute with four decimal places, store two, and stop agonizing
> over it.
But "computing with four decimal places" MAY be harder than doing it more
accurately. The banks are probably doing the calculations in BCD. Although we
can, I don't think that is the likely implementation.
Remember, if we design things properly, we can change the internal
representation without having any real effect on the bulk of the system.
> > For example, before decimalization, it would have been 1/240 Pound
> > Sterling. I think that someone indicated that it is 0.05 Swiss Franc,
> > etc.
>
> Hmmmm...I wonder how international banks handle the problem.
Probably in either BCD or, in the case of the old British Currency, Pounds,
Shillings, Pence.
Remember that the requirement is only that I be able to handle the amounts.
Most banking applications are defined in terms of the character fields of the
I/O record. They rarely use binary because the I/O conversion dominates the
math.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
