Re: Lots in Account screen : Value sign

[Alex Aycinena]

>
> -- Forwarded message --
> From: Linas Vepstas 
> To: "Frank H. Ellenberger" , Geert
> Janssens 
> Cc: GNUCASH devel 
> Date: Wed, 24 Aug 2016 23:12:54 -0500
> Subject: Re: Re: Lots in Account screen : Value sign
> Wow... you're asking me to remember something from 12 years ago ...
>
> Here's my best guess: for a "lot", I had the mental model of starting with
> 100 of something ... e.g. 100 cans of paint, and then selling them off in
> dribs and drabs. Thus, the first entry, that opens the lot, has a sign that
> differs from all the others.  By definition, there can be only one such
> entry in the lot, -- by definition, all of the other entries must have the
> opposite sign. Lots can only shrink and get smaller.
>
> So -- I buy 100 cans of paint at $10 per can, then sell 20 at $15 a can,
> then sell 35 at $17 a can, then sell 45 at $12 a can, closing out the lot
> (forever, since all the paint in that lot is now gone).
>
> Lots could be shares of stock, could be cans of paint, cartons of milk
> marked by expiration date -- anything that is naturally counted in
> non-monetary units, and come in lots (i.e. you want to sell/use/drink the
> oldest milk first, so you really do want to track the date/lot-number).
> More abstractly, lots could be shipments to a customer, unfilled or
> partially filed orders, whatever --
>
> With this concept of a lot, its impossible to add more to the lot -- once
> opened, it can only be depleted.  Thus, the split that opens the lot is
> "special". By assumption, its the very first split; it doesn't really make
> sense for it to be any other. That is, I can't sell cans of paint that I
> don't yet have.  At least, that was the initial conception of how lots
> work.
>
>
For stocks, you could have selling short, that is, selling shares you don't
already own at a future date and then buying them at a future date to
deliver when due hoping to make money on a drop on their value. Not your
typical stock transaction, though.


> Now, we all have read the news about corporations that sell things before
> the customer takes delivery, leading to various accounting scandals. I
> suppose there are other legitimate uses of lots, which somehow get
> overdrawn before they are stocked up.  Or something.  But that got
> confusing to think about, and was not a part of the design.
>
> I'm not at all clear as to why payments or invoices are going through the
> lot system, other than maybe you bill someone $100 and they pay you in
> installments?  Ans so you want to match up the installments with the
> original invoice, until its paid off?  I guess that's a valid use of
> lots... If the sign is wrong for that special, first entry, then that's the
> fault of whomever opened that lot.
>
> --linas
>
>
Alex
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Lots in Account screen : Value sign

[Geert Janssens]

On Wednesday 24 August 2016 23:12:54 Linas Vepstas wrote:
> Wow... you're asking me to remember something from 12 years ago ...
> 
Your memory is good! Though it reminds me we're not only commenting our 
code for other devs, but also for our future selves...

> Here's my best guess: for a "lot", I had the mental model of starting
> with 100 of something ... e.g. 100 cans of paint, and then selling
> them off in dribs and drabs. Thus, the first entry, that opens the
> lot, has a sign that differs from all the others.  By definition,
> there can be only one such entry in the lot, -- by definition, all of
> the other entries must have the opposite sign. Lots can only shrink
> and get smaller.
> 
> So -- I buy 100 cans of paint at $10 per can, then sell 20 at $15 a
> can, then sell 35 at $17 a can, then sell 45 at $12 a can, closing
> out the lot (forever, since all the paint in that lot is now gone).
> 
> Lots could be shares of stock, could be cans of paint, cartons of milk
> marked by expiration date -- anything that is naturally counted in
> non-monetary units, and come in lots (i.e. you want to sell/use/drink
> the oldest milk first, so you really do want to track the
> date/lot-number). More abstractly, lots could be shipments to a
> customer, unfilled or partially filed orders, whatever --
> 
So far so good...

> With this concept of a lot, its impossible to add more to the lot --
> once opened, it can only be depleted.  Thus, the split that opens the
> lot is "special". By assumption, its the very first split; it doesn't
> really make sense for it to be any other. That is, I can't sell cans
> of paint that I don't yet have.  At least, that was the initial
> conception of how lots work.

According to the code that "very first split" is determined by date 
posted. This works well for the scenarios you describe above. It fails 
however for business transactions of which you provide one example 
below.
> 
> Now, we all have read the news about corporations that sell things
> before the customer takes delivery, leading to various accounting
> scandals. I suppose there are other legitimate uses of lots, which
> somehow get overdrawn before they are stocked up.  Or something.  But
> that got confusing to think about, and was not a part of the design.
> 
That's fair. So I'll need to think about how to extend the design to 
work well for the extra business use cases as well.

> I'm not at all clear as to why payments or invoices are going through
> the lot system, other than maybe you bill someone $100 and they pay
> you in installments?  Ans so you want to match up the installments
> with the original invoice, until its paid off?  I guess that's a
> valid use of lots...
Payments in installments, pre-payments, over-payments, paying multiple 
invoices with a single payment,... all these have been made possible by 
using lots.

> If the sign is wrong for that special, first
> entry, then that's the fault of whomever opened that lot.

It did ignore the assumptions made in the original implementation. It 
seems the date based method of finding the opening split is too limiting 
to accommodate the business requirements. But that's fine. I can work 
from here to get that fixed.

Thanks for the design background!

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Re: Lots in Account screen : Value sign

[Linas Vepstas]

Wow... you're asking me to remember something from 12 years ago ...

Here's my best guess: for a "lot", I had the mental model of starting with
100 of something ... e.g. 100 cans of paint, and then selling them off in
dribs and drabs. Thus, the first entry, that opens the lot, has a sign that
differs from all the others.  By definition, there can be only one such
entry in the lot, -- by definition, all of the other entries must have the
opposite sign. Lots can only shrink and get smaller.

So -- I buy 100 cans of paint at $10 per can, then sell 20 at $15 a can,
then sell 35 at $17 a can, then sell 45 at $12 a can, closing out the lot
(forever, since all the paint in that lot is now gone).

Lots could be shares of stock, could be cans of paint, cartons of milk
marked by expiration date -- anything that is naturally counted in
non-monetary units, and come in lots (i.e. you want to sell/use/drink the
oldest milk first, so you really do want to track the date/lot-number).
More abstractly, lots could be shipments to a customer, unfilled or
partially filed orders, whatever --

With this concept of a lot, its impossible to add more to the lot -- once
opened, it can only be depleted.  Thus, the split that opens the lot is
"special". By assumption, its the very first split; it doesn't really make
sense for it to be any other. That is, I can't sell cans of paint that I
don't yet have.  At least, that was the initial conception of how lots work.

Now, we all have read the news about corporations that sell things before
the customer takes delivery, leading to various accounting scandals. I
suppose there are other legitimate uses of lots, which somehow get
overdrawn before they are stocked up.  Or something.  But that got
confusing to think about, and was not a part of the design.

I'm not at all clear as to why payments or invoices are going through the
lot system, other than maybe you bill someone $100 and they pay you in
installments?  Ans so you want to match up the installments with the
original invoice, until its paid off?  I guess that's a valid use of
lots... If the sign is wrong for that special, first entry, then that's the
fault of whomever opened that lot.

--linas



On Wed, Aug 24, 2016 at 11:07 AM, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Linas,
>
> do you remember the reason?
>
> Regards
> Frank
>
>  Weitergeleitete Nachricht 
> Betreff: Re: Lots in Account screen : Value sign
> Datum: Tue, 23 Aug 2016 17:51:30 +0200
> Von: Geert Janssens 
> Organisation: Kobalt W.I.T.
> An: gnucash-devel@gnucash.org
>
> On Thursday 18 August 2016 10:31:54 Chris Good wrote:
> > Hi,
> >
> >
> >
> > I'm documenting using lots to calculate investments capital gains.
> >
> >
> >
> > Please see the attached screenshot.
> >
> >
> >
> > The sign of the Value in the 'Splits free' panel seems inconsistent.
> >
> > Why is the sign of the initial acquisition +ve, but -ve for the
> > following 2 reinvested dividends?
> >
> > The program contains the following:
> >
> > gnucash/src/gnome/dialog-lot-viewer.c line 523:
> >
> >
> >
> > /* Value. Invert the sign on the first, opening entry. */
> >
> > currency = xaccTransGetCurrency (trans);
> >
> > valu = xaccSplitGetValue (split);
> >
> > if (node != split_list)
> >
> > {
> >
> > valu = gnc_numeric_neg (valu);
> >
> > }
> >
> >
> >
> > I'd like to explain why this is done?
> >
> > Perhaps something to do with the Business scrubbing?
> >
> >
> >
> > Regards,
> >
> > Chris Good
>
> Hi Chris,
>
> I can only speak about the business features. I have 0 experience with
> investments capital gains.
>
> From that business perspective, I believe you have found a bug in the
> code. It seemed to have slipped by when I merged a patch in 2011 which
> introduces the pane with unassigned splits.
>
> The code that inverts the first split was originally introduced by Linas
> in 2003 (in commit https://github.com/Gnucash/gnucash/commit/1a997993 )
> for the other pane, the one displaying the splits *in* a selected lot. I
> don't know why he introduced this behavior. There is no additional
> explanation with the commit.
>
> It was later reused for displaying splits in the free splits pane.
> However I don't think it makes sense there to revert the first free
> split. That's just some arbitrary split. So I believe that's wrong.
>
> And to be honest, I don't understand the motivation either to revert the
> sign on the first split in the lots either. For the current (business)
> code the result is rather arbitrary. Sometimes the first split is a
> payment, sometimes it's an invoice. Whichever is first gets its value
> reversed. So sometimes all values are negative, sometimes they're all
> positive. And the amounts alter negative/positive to properly balance
> the lot.
>
> So from a business perspective, this implementation doesn't make sense
> at all. I don't know whether it does 

Re: adjust-dpi.sh rounding problem

[Geert Janssens]

On Thursday 25 August 2016 09:34:34 Chris Good wrote:
> Thanks for your reply.
> It's annoying that identify doesn't use the locale decimal separator.
> BTW, my locale is en_AU.UTF-8.
> 
> Are you sure bash printf doesn't round? It does for me in Ubuntu,
> although I was surprised to see 0.005 sometimes does not round up
> (I guess it's just the typical floating point rounding problem).
> printf "%.2f\n", 1.235
> 1.24
> printf "%.2f\n", 4321.235
> 4321.23   ###???###
> printf "%.2f\n", 4321.2351
> 4321.24
> LC_ALL=nl_BE.UTF-8 printf "%.2f\n", 4321,235
> 4321,23
> LC_ALL=nl_BE.UTF-8 printf "%.2f\n", 4321,2351
> 4321,24
> 
> The 0.005 sometimes not rounding up will not be an issue for
> adjust-dpi.sh as the numbers are a lot closed to the rounded value
> than 0.005.

I can't reproduce the truncating behavior today. It rounds as you 
describe so I'll just forget about that. I probably got confused at some 
point.

> 
> Anyway, I decided to use awk to strip the trailing
> "(space) PixelsPerCentimeter"
> and do the rounding in one step.
> 
> When you get a chance (or some-else on Fedora 23?), could you please
> test: echo 4321.159 | awk '{ printf("%.2f\n", $1) }'
> 4321.16
> 
Works as expected. Good choice!

> I'm also surprised to see my awk is also NOT using the locale decimal
> separator:
> $ LC_ALL=nl_BE.UTF-8 echo 4321,159 | awk '{ printf("%.2f\n", $1) }'
> 4321.00
> LC_ALL=nl_BE.UTF-8 echo 4321.159 | awk '{ printf("%.2f\n", $1) }'
> 4321.16
> 
> I've never before had to worry much about different locales - Oh well,
> I'll get there :-)

This seems to work fine in all locales. Thanks!

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel