Re: Discount Field

["Chris Travers" <..hidden..>]

On Sat, Dec 6, 2008 at 9:18 PM, Luke <..hidden..> wrote:
> The below quoted old message, has raised something I've been meaning to
> bring up for some time.
>
> What are the pros, cons, and chances, of adding a discount field?  An
> overall discount field, that is, under subtotal.
>
> I would like to be able to adjust the over all final price, either by a
> hard dollar amount, or by a percentage.

I think that one has multiple use cases in this with multiple
different sets of requirements.  I think the first stage is to try to
clear this up by separating the use cases and understanding the
requirements of each individual use case.  I don't think "a discount
field" will solve your problems, and will probably introduce other
issues if we proceed without understanding these requirements fully.
>
> E.G. "Hey, you guys really shipped my last order late--how about twenty
> bucks off on my current invoice?"
> "Well, that wasn't us, it was the shipper, but certainly, let me just
> enter a 20 into discount, and...done!"

Currently, what you would do is enter a $20 payment against a discount
expense account on the invoice.   I am not sure you can simply exempt
sales tax for the $20 because it becomes impossible to tell in a mixed
taxable/non-taxable invoice what is really taxable.

>
> Percentage can be done with line items, but even then you want to take 10%
> off of an order, it might just be quicker to enter "10%" into a field
> called discount, and not into 52 different line item fields on a big
> order worthy of such discounts.

In a case like this I think you would need a new field, and probably
make this the default (either by javascript or server-side Perl
script) for all discount fields.  This would not be hard to do.
>
> Even the field name could be variable: if it is a text field defaulting to
> a defaults "name of discounts" entry, you could call it "Discount",
> "Write-Off", or whatever, as described below, and then alter it at
> "runtime" to say something more descriptive if necessary.

It seems to me that two different use cases are being addressed here:
1)  Discounted per-unit prices globally for the invoice.
2)  Credits against an invoice (already doable using payments)

Of course you also have a third which is early-payment discounts (added in 1.3).

All three of these have sales tax and accounting differences, and I
don't think one single interface would work for all three.  Hence I
think one has:

1)  Use case 1:  credit to invoice.  Solution is documentation since
this can be done already
2)  Use case 2:  Default per-line discounts on invoices to avoid
repeat data-entry.  This is a valid feature request.
3)  Use case 3:  Early payment discount, already to be addressed in 1.3.

Does this seem about right?
Best Wishes,
Chris Travers