Now that 3.11 is truly out, the budget editor and report should now behave
exactly as in 3.7
4.0 should also behave similarly. Please verify, and any bug reports and
fixes will apply onto 4.x series.
On Fri, 8 May 2020 at 12:58, Christopher Lam
wrote:
> 3.11 being due in 3 weeks' time, the candi
3.11 being due in 3 weeks' time, the candidate fix for budgets is merged in
daily builds. The next build after 4th May in
https://code.gnucash.org/builds/win32/maint/ will have the budgets reverted
to 3.7 behaviour.
On Wed, 29 Apr 2020 at 20:05, John Ralls wrote:
>
>
> > On Apr 29, 2020, at 11:4
> On Apr 29, 2020, at 11:45 AM, Phil Longstaff wrote:
>
> Agreed.
>
> It is correct that Assets = Liabilities + Equity uses only positive values.
> However, each balance is a credit balance or a debit balance. It is
> perfectly reasonable to associate one of those types of balance with
> posi
Agreed.
It is correct that Assets = Liabilities + Equity uses only positive values.
However, each balance is a credit balance or a debit balance. It is
perfectly reasonable to associate one of those types of balance with
positive numbers and the other with negative numbers.
On Wed, Apr 29, 2020 a
> On Apr 29, 2020, at 1:42 AM, Geert Janssens
> wrote:
>
> Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls:
> > > On Apr 28, 2020, at 7:27 AM, Geert Janssens
> > > wrote:
> > >
> > > However numbers are not just meant for displaying, one needs to do
> > > calculations on them as w
Am 29.04.20 um 10:42 schrieb Geert Janssens:
> Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls:
>>> On Apr 28, 2020, at 7:27 AM, Geert Janssens
>>> wrote:
>>>
>>> However numbers are not just meant for displaying, one needs to do
>>> calculations on them as well. And at that point signs
On Wed, 29 Apr 2020 at 08:36, Geert Janssens
wrote:
> Finally I want to clearly point out the actual inconsistency in the budget
> code is not whether it
> uses a signed representation or a debit/credit notation. The issue is it
> stores the budget data in
> a way that's dependent on the Sign rev
Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls:
> > On Apr 28, 2020, at 7:27 AM, Geert Janssens
> > wrote:
> >
> > However numbers are not just meant for displaying, one needs to do
> > calculations on them as well. And at that point signs will matter.
> > Whether a certain number incr
Adrien,
As David Carlson points out not everyone knows how to interpret debit and
credit. So moving
away from a signed representation towards Debit/Credit representation simply
moves the
confusion with it. Now one has to know whether a number marked as debit was
really a debit or
not. That w
Please keep in mind that budgets may also be used by people with no
accounting training, like myself, who get overwhelmed by the terms debit
and credit and where each is properly used.
On Tue, Apr 28, 2020 at 1:23 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
>
>
> > On Apr 28, 20
> On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens
> wrote:
>
> What I take from all this is that as long as you display data in two columns
> (a debit and a credit) you can follow the logic as you suggest.
Most likely, that’s what I thought at first too, but I suppose a notation like
“D
> On Apr 28, 2020, at 7:27 AM, Geert Janssens
> wrote:
>
> However numbers are not just meant for displaying, one needs to do
> calculations on them as
> well. And at that point signs will matter. Whether a certain number increase
> or decrease your
> balance is a matter of sign.
Maybe w
Op dinsdag 28 april 2020 15:58:30 CEST schreef Adrien Monteleone:
> Geert,
>
> I concur.
>
> As long as the internals treat the equation as set to equal zero, then
> signage is necessary and it should be consistent. I appreciate the efforts
> being made to achieve this.
>
> My (pie in the sky) r
Geert,
I concur.
As long as the internals treat the equation as set to equal zero, then signage
is necessary and it should be consistent. I appreciate the efforts being made
to achieve this.
My (pie in the sky) request for consideration is the idea that such a treatment
of the equation is inc
My simplistic view on this: if there is going to be confusion anyway, let's at
least make it
consistent.
We have the sign reversal strategies in there to alter gnucash number
presentation behavior. To
me it would make sense this affects normal transactions the same way as it
would reports as
No sorry, Windows builds are generated only for maint (3.1x) and master
(3.9x eventually 4.x) builds. It would be very disruptive for these
branches to receive beta commits and reversals. So, derek's script scans
the beta branch on my github fork daily for any changes, and builds a
flatpak if it ha
Is there a windows build? I have a linux vm so might be able to test the
flatpak, but windows would be easier
On Mon, Apr 27, 2020 at 4:52 PM Christopher Lam
wrote:
> Labelling issues aside, is there anyone who would be willing to beta test?
>
> On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, <
> as translator I have a problem with "Inflow to" in this context. I had
> only expected "Inflow from" and "Outflow to".
>
> Frank
Good point. Should just use Inflow and Outflow to avoid nonsense terms.
___
gnucash-devel mailing list
gnucash-devel@gnucas
I do some testing this evening.
Regards,
Adrien
> On Apr 27, 2020 w18d118, at 3:51 PM, Christopher Lam
> wrote:
>
> Labelling issues aside, is there anyone who would be willing to beta test?
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.o
Labelling issues aside, is there anyone who would be willing to beta test?
On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, <
adrien.montele...@lusfiber.net> wrote:
> Thanks Phil, so I’m not completely insane then.
>
> I too try to remember to factor in signs because GnuCash works that way. I
> wa
Thanks Phil, so I’m not completely insane then.
I too try to remember to factor in signs because GnuCash works that way. I was
just throwing in my 2¢ for taking a step back for perspective that maybe can be
considered in a future release. (5.0 maybe?)
As for danger in generating confusion, the
I agree with what you say about positive and negative with respect to
budgeting assets and liabilities. However, if I have a transaction which
pays down a loan, and then add that loan to the budget report, the actual
value is displayed as negative. That is why I budget paying down a loan
with a neg
I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ for
anything but income.
However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should even be
there. It produces too much confusion with signs.
Now I have to be concerned with interpreting the sign to be the op
Hi,
Am 27.04.20 um 06:08 schrieb Christopher Lam:
> [image: budget-view.png]
as translator I have a problem with "Inflow to" in this context. I had
only expected "Inflow from" and "Outflow to".
Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash
Thank you Phil.
I'm sure you know the issue with existing budgets - they do not behave as
expected when the Estimate tool is used to pre-fill cells, when
sign-reverse isn't credit-accounts.
There is *another* issue (not documented afaik in bugzilla) about budgets:
the totals do not total budget-a
Hi Chris,
thanks for taking this on. I am sorry I don't have more time to commit to
the project.
I don't like the terms "Outflow to Asset" and "Inflow to Liability".
For Assets, here is how I see a budget being used.
If I want to plan to put money into savings (an asset), I will have a
budget w
Would anyone object to the following (last) amendment to budget totals:
separate the account types, and add 'Remaining to budget' line which
implements the budget-to-zero facility, and *will* replicate the 3.7
behaviour.
(Note the totals *will* be renamed to "Total Assets" "Total Expense" etc.)
[i
Thank you for trying Adrien. This budget bug is proving to be a major
headache. I really need more beta testers, especially with ability to build
from my branch.
Of note:
* previous methodology was: in a period, budgeted income, minus budgeted
expense and any asset/liability transfers, must result
I just posted my first result and impression to the bug report, though I’m sure
you saw that already. (this is more for the benefit of list readers not
following the bug)
The signs aren’t making sense, and the amounts aren’t adding up correctly.
Regards,
Adrien
> On Apr 10, 2020 w15d101, at 5:
Next addendum: your existing budget data will behave well when reverse
balances=credit accounts, but the *featured* data will be stable with *any*
reverse balances global preference option.
On Fri, 10 Apr 2020, 11:28 am Christopher Lam,
wrote:
>
>
> On Fri, 10 Apr 2020, 10:20 am Christopher Lam,
On Fri, 10 Apr 2020, 10:20 am Christopher Lam,
wrote:
> Deadline is 11 April at noon GMT, so, about 34 hours from now.
>
> For both: *existing* datafile and especially *4.x-featured *datafile (in
> bug report).
>
> Please test:
> - creation of budget amounts
> - use estimate to prefill cells
> -
Okay, I’ll see what I can do. First, is to figure out how to get that flatpak
installed from that link.
I’ve never messed with Flatpaks, but I’m guessing I need to add a repo and then
I should be able to install. Researching now...
Regards,
Adrien
> On Apr 9, 2020 w15d100, at 9:20 PM, Christop
Deadline is 11 April at noon GMT, so, about 34 hours from now.
For both: *existing* datafile and especially *4.x-featured *datafile (in
bug report).
Please test:
- creation of budget amounts
- use estimate to prefill cells
- all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
-
Thank You! This makes it so much easier to test. I’ll give the flatpak a spin
and see what I find. I still haven’t set up a build environment for Mac yet.
(and watching a recent thread on the subject makes it look daunting compared to
Linux)
This is a busy weekend for me though. What kind of ti
2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/
flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use
between 2020-04-04 and 2020-04-10
On Fri, 10 Apr 2020 at 01:38, Christopher Lam
wrote:
> This topic is about budgets.
>
> We now know that budge
This topic is about budgets.
We now know that budgets are currently inherently flawed: they *assume*
that sign-reversal = credit-accounts, and do not work well at all with any
other sign-reversal option. In addition, there was a feature request (bug
781345) that introduced budget equity into the e
36 matches
Mail list logo
