Re: Discount Field

["David Mora" <..hidden..>]

Hi i just saw this messages, i built the early-payment discounts on
1.3, if you are going to work
on line-items discounts, please feel free to review/ask the work done
there so we can have something
similar in the three cases you just mentioned.

If you want the details of how this is working on 1.3 please feel free
to ask, i (hopefully) think
i remember everything i did and i will be more than happy to help you
get this going...

Cheers!!

DM

2008/12/12 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
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Ledger-smb-users mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>