> Hendrik Boom <[EMAIL PROTECTED]> writes:
> > Now I don't expect you to run and fix this (though it would be nice)
> > immediately before a stable release, for fear of disturbing
> > something else.
>
> This period of time is for bug fixes, and you've found a bug, so it's
> the perfect time to fix it.
>
> The question is, what's the right way to fix the problem? In your
> ideal solution, would Gnucash merge the two splits into one, following
> the Cash account's representation of the event, or split the Cash
> transaction, following the Checking account's representation?
Let's see.. In chequing,
12/04 cash cash 300.00 X 68.88
1998 SPLIT
[cash] 200.00
groceries
allowances 90.00
allowances
[cash] 10.00
cash
in cash,
12/04 cash 210.00 49,641.91
1998 memo:
cat: [Checking]
There are two Quicken accounts involved - chequing, and cash.
There are three gnucash accounts involved - chequing, cash, and allowances.
I had trouble deciding between your two choices, until I remembered that
we do have multiple entry bookkeeping. This means we can choose how to
split a little more cunningly that Quicken did.
I now see the following possibility:
One transaction, that
debits the chequing account by $200, memo groceries
debits the chequing account $10, memo cash
debits the chequing account $90, memo allowances
credits the allowance account $90,
credits the cash account $210
This way the Quicken splits become gnucash splits in the same accounts.
And Quicken splits that are associated with a category end up associated
with the appropriate account.
This resolution seems to specialize properly to the way you handle other
transfers and categories.
-- hendrik.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
