On Wed, Feb 24, 2010 at 12:11 PM, Luke <[email protected]> wrote: > On Wed, 24 Feb 2010, Chris Travers wrote: > >> This will affect the precision possible, not the method of calculating >> the discount. > > Chris > > Irrespective of precision from the customer point of view, wouldn't it > make some sense to do all internal calculations at the highest precision > available, and only round at the end of, in this case, a line item?
This would be a substantial change in behavior with no regression and I would want to see this better discussed before pushing something like this even into a development branch, although I would like to see this problem tacked heavily on 1.4 as we do the total rewrite of the invoice system. I am a little nervous about fractional cents floating around and the possibility or bias in rounding that could develop. > > A slightly more complex method, of which I have not fully considered the > ramifications, is to allow multiple stages of precision rounding. > > First stage (inside a line item): maximum precision > Second stage (line total): user specified - higher = more accuracy > subtotal is based on second stage > taxes, etc. are calculated on second stage > Third stage (total): user specified - the end result receivable > > It may be troublesome to do stages 2 and 3 given taxes, and the things > we've been talking about re cash based handling of collected sales taxes, > in which case stage 3 may need to move to stage 2. > > I envision it something like this: > > [S1] itemprice (imaginary) * discount (imaginary) = 105.04017437 > 105.04017437 * quantity (5) = 525.20087185 > [S2] 525.20087185 round to pre-subtotal precision (3): 525.201 > No tax or other subtotal to total modifiers > [S3] total rounded to total precision (2) = 525.20 > > I have run into companies which do all intra-invoice calculations at > something like a precision of 4, but then round the subtotal to a > precision of 2, most likely with a round in their favor (I.E. up). > That's what I'm angling for here. That might work. > > > As we revise the invoicing system I would like to be able to handle >> "lot prices" but some additional thought needs to go into how that >> would work. > > Add a quantity field to the price matrix, and sort on quantity descending? That's not really what I was envisioning. More along the lines of: Buy product X in cartons of 24 units for $14.99 per carton. Our current approach doesn't work well here which is a major limitation for many users. However a lot could go the other way too. However, this would require rewriting the whole way we do COGS, not that such would be a bad thing. Lots though could go the other way too, and allow for something like "I will sell you X of product for Y price total." These could be defined ahead of time and function kind of like ad-hoc assemblies (i.e. not stocked separately from sale). One might even allow the extended price to be user-editable. Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
