Thanks Frank
That was pretty much what i thought the situation would be. Perhaps we
should add a note about the flow somewhere That is easily accessible to
users in the documentation so that users have a better idea of where to look
for up to date recent and rapidly changing information. I will se
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
Hi David,
starting from the accessability, I think the practial persistence is as
follows:
IRC < email < wiki:FAQ < wiki:theme_page < docs
Examples:
Geert or John explain me something in IRC and I am pretty sure I will
need it next year again, I copy it in a page below
Project_Administration, Cod
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
Thank you all; having considered all feedback, there will be an upcoming
3.10 with the old reconcile behaviour reverted.
I agree that this "fix", although correct in principle, was premature
because it could not handle invalid data.
The reason I feel/felt that rollback this "fix" and to tolerate
Christopher
My remaining concern is that fixing any incorrect reconciliation dates is at
this stage a manual procedure requiring the editing of the XML file (SQL
database users?). In addition it requires sufficient knowledge of the XML
file structure to be able to correctly identify which accounts
Christopher,
I understand your frustration at trying to help and getting a negative
response. In trying to fix one problem, you have unwittingly waded into a
bigger one.
Your message raises a couple of points. First, this rollback need not be
forever. It could wait until such time as the rec
I don’t see #1 as ‘forever’ but ‘until a better option can be crafted’.
#2 gives flexibility. To reduce confusion, should it be selected by default?
(only those who intentionally need to reconcile future dates are the users
who’ll have to grok it)
How viable is:
3b. Add this to the Check & Re
Op dinsdag 7 april 2020 18:37:25 CEST schreef Derek Atkins:
> Hi,
>
> On Tue, April 7, 2020 11:47 am, Dale Phurrough wrote:
> > Cool use of cleared/reconciled for expenses. I can follow that general
> > approach.
> > I do have an inquiry regarding the need for the future when reconciling.
> > (Wha
Regarding reverting:
It is too difficult to create a UI to modify reconciled dates. Options to
fix this are:
1. roll back this change and tolerate the invalid data. This means any
progress on that matter is hindered forever.
2. allow this change depending on a user-selectable book property "Use
14 matches
Mail list logo
