On Fri, Jan 20, 2017 at 9:04 PM, John Wiegley <[email protected]> wrote:
>>>>>> "BE" == Brian Exelbierd <[email protected]> writes:
>
> BE> This is a horrible hack:
>
> BE> 2017-01-01 foo
> BE> Expense:foo 0.25 PERC
> BE> Expense:bar 0.33 PERC
> BE> Expense:zed 0.42 PERC
> BE> Income -$20
>
> If you just need a calculator, then:
>
> 2017-01-01 foo
> Expense:foo ($20 * 0.25)
> Expense:bar ($20 * 0.25)
> Expense:zed ($20 * 0.50)
> Income -$20
>
> Still ugly, but a bit more to the point. And it won't balance if you don't
> allocate the amounts 100%.
>
(Sorry question seems to be morphing as responses are happening!)
OK - - - thanks - - - this helps but - - - - - is there a way to defining this?
Sort of if the account entered is foo at amount xx.xx then I would call
'something' (don't know what to call it - - - sorry) and then in my text
file (I'm using leafpad because I'm finding it faster for text entry than vi
which is my low level text editor of choice) I would see 4 lines of text
populated with amounts related to xx.xx.
This means that I could have foo, foo1, foo2 . . . having different
formulas for each. With them pre-defined then a clerk would not
have to use math to accurately enter these kind of invoices. (Sorry,
my experience is that most people are math phobic even if they are
capable of doing data entry.
short example for the entry item.
2017-01-01 foo
Expense:foo (0.20($20 * 100/105))
Expense:bar (0.80($20 * 100/105))
Expense:tax (on foo portion) (0.20($20 * 5/105))
Expense:tax (on bar portion) (0.80($20 * 5/105))
Income -$20
Is this how I could be entering it?
I haven't been because that formats 'messy' and that makes it harder
to see if there are errors in input.
Your indicated solution would work well for nice percentages but
one of the things I'm running into is that at the checkout taxes are added
to the aggregate total applicable. When the individual items are separated
out and the applicable tax portion applied to those specified items with
normal mathematical rounding rules overall totals change because of the
rounding. This tends to show up when there are more than a couple items
on the invoice. This is when it would be nice if ledger carried numbers
internally to a greater precision than is displayed - - - likely not practical
but that high internal precision with a displayed 2 digit (for NA currencies
anyway) would reduce the need to go back and drop at most a few cents
from some of the items (few cents being a cent from 2 or 3 of the items
being affected by the rounding).
example for multi-item rounding error
There is a 2 level tax (some items are no tax, some items (most) have
tax A and B, some have only tax A some only have tax B (and to make
sure its kinky, tax B is for a some items (rarely) different).
2017.01.20 foo sales co
Expense: foo A: 1234.12.12.12 (tax A no tax B) 123.12
Expense: foo B: 2234.23.23.23 (tax A tax B) 23.45
Expense: foo C: 3234.32.32.32 (tax A tax B) 12.12
Expense: foo D: 4234.42.42.42 (tax A tax B) 51.23
Expense: Tax A: 5234.00.00.00 x.xx
Asset: back account ert: 1211.01.01.01 total
amount
My jurisdiction rules tell me that tax B is to be included in the cost of
the item but because tax A, that I have paid is refundable to me, then
I need to break it out and keep track of it. When I charge tax A or tax
B then I need to remit it. With tax A my tax amount payable is reduced
by the amount of tax A that I have paid (as a business).
Sorry this isn't straightforward but then we're talking about taxes and
they're anything but straightforward!
With thanks for the assistance and for a 'record keeping' system that
I'm finding useful accurate and easy to use!!
Dee
--
---
You received this message because you are subscribed to the Google Groups
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
