Re: Discount Field

[Luke <..hidden..>]

On Sun, 7 Dec 2008, Chris Travers wrote:

> On Sat, Dec 6, 2008 at 9:18 PM, Luke <..hidden..> wrote:
> > 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.

You're right, and I hadn't considered it, because almost invariably, I do 
not run into mixed taxability invoices.  I can probably count on one 
finger the number of times I have had one of those in the last few years.
That is solvable, of course, by applying it against specific portions of 
the invoice, but that is most highly messy, and brings us back to where we 
are now, so is not worth it.

> > 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.

I would do both, actually--if JS is active, then it will work immediately; 
otherwise on the next update.
(I still use text browsers quite often, and few of them support JS, so I 
still try to keep that in mind)
In either case, I like this idea.

> 1)  Discounted per-unit prices globally for the invoice.
> 2)  Credits against an invoice (already doable using payments)
[(3)]> Of course you also have a third which is early-payment discounts 
> (added in 1.3).

I have always thought that doing that would require making customers 
behave 
more like accounts, which would allow one to apply specific expenses 
to individual customer accounts, and then generate an invoice at the end 
of a period, more in the nature of a statement.  but I digress...

I assume what you are describing in (2) applies when one is crediting in 
the case when no actual income has been received, but the total needs to 
be reduced for some other reason, which is, effectively,  what I was 
talking about.

 > 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.

Consider this feature requested.  The JS version would be relatively 
simple, I believe.
The question arises: should it apply exclusively (overwriting existing 
values), or inclusively (leaving current values alone), or cumulatively?
Easiest and most reasonable would seem to me to be the inclusive version, 
because it would allow one to easily go back and alter individual fields.

If it is done this way, it should also not be persistent on updates--it 
should apply immediately, or during the first update, and then reset to 
nothing, so that fields which are cleared will remain cleared when 
updated.  We would then need a "clear all discounts" button.

Luke