Re: [GNC-dev] WebKitGtk now defaults to Gtk4

[Christopher Lam]

On Sun, 19 Nov 2023 at 12:01, john  wrote:

> I spent some time this afternoon poking at webkit replacement. The options
> I found are:
> * Keep using WebKitGtk
> * Figure out how to wrap a native (meaning Apple AppKit or Microsoft)
> WebView in a GtkWidget
>

^ This one would be my vote if it's possible. As long as we can use an
evergreen browser, it should do the trick.


> * Send the HTML/JS/CSS to the default browser. This will lose the links to
> GnuCash objects like transactions
> * Configure a GtkTextView to understand HTML tags. This doesn't support
> charts, printing, or PDF export.
> * Write reports directly to PDF. There are libraries out there but I
> didn't find any FLOSS ones that mention CSS styling or drawing charts in
> their feature sets.
>
> Any other ideas?
>
> Regards,
> John Ralls
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Scripting Gnucash actions without UI

[Christopher Lam]

Thanks Liz... With the full power of scheme (or python) it will be
relatively straightforward to customise these calculations. There's an
example script in the GitHub pull request, and it does interact via command
line to input some transaction details, summarises the transaction and asks
confirmation before committing the change.

It does require some knowledge of programming and learning the gnucash API,
but won't require building the full gnucash code.

Other ideas are possible: determine the balance of an account at a
particular date, download transactional, business or pricing data from an
external source or any format (json,TSV), submit anything to an external
recipient, etc.

Implementing such a change effectively raises the scheme code from being a
report-only mechanism to unlocking full scripting, and also unlock python
scripting to more users.

On Fri, 13 Oct 2023, 5:52 am Liz,  wrote:

> On Sun, 8 Oct 2023 17:51:40 +0800
> Christopher Lam  wrote:
>
> > It would thus be useful to know the types of tasks that users wish to
> > automate. I'll start:
> >
> > Every quarter, I personally tally up the GST account balances, which
> > allows me to submit to the tax office. I currently use the "Income
> > and GST Statement" report for tallying. I will also create some
> > transactions which will offset the GST accounts back to zero. This
> > could easily be automated.
>
> My GST is more complex
> with two different vehicles, company tax and the income tax to be
> reckoned as well.
> Vehicles only have a proportion of the GST to be put in the
> calculations.
>
> I attach my Scheduled transaction just for the amounts to be given to
> the tax office.
> There are also a series of scheduled transactions for the splits in the
> GST for vehicle expenses.
>
> Liz
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Scripting Gnucash actions without UI

[Christopher Lam]

Dear Users

I'm aware there's demand for automated scripting Gnucash activity such as
entering transactions with custom formulas more complex than the SX
facility will allow, determining end-of-quarter calculations etc.

There's a pending PR at https://github.com/Gnucash/gnucash/pull/1794 which
will unlock it (with a scheme script... or a python script if someone
proficient can code it), and *will* allow the above, and* can* offer some
interactivity (e.g. "please enter the transaction description" -- see the
PR for such an example),* and also* potentially unlock other UI toolkits.
>From my understanding this is a facility that the original GnuCash code
from 1997 or so offered.

We are not willing to provide custom-built solutions for users (not even
with money offers); and I do not think it's a good idea to add custom
scripts into the code. Users could share the scripts among themselves at
their own maintenance risk. However, if users are needing help for such
tasks, we can consider augmenting the software with api calls which can
assist.

It would thus be useful to know the types of tasks that users wish to
automate. I'll start:

Every quarter, I personally tally up the GST account balances, which allows
me to submit to the tax office. I currently use the "Income and GST
Statement" report for tallying. I will also create some transactions which
will offset the GST accounts back to zero. This could easily be automated.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] ANNOUNCE: GnuCash 5.4 Released

[Christopher Lam]

Yes, some cpp conversion. Mostly .c renamed to .cpp with minimal changes.
See https://github.com/Gnucash/gnucash/pull/1708 and
https://github.com/Gnucash/gnucash/pull/1753.
Whether this is an improvement or not is yet to be decided:
https://github.com/Gnucash/gnucash/pull/1784

On Mon, 25 Sept 2023 at 15:06, Jean Laroche  wrote:

> Wow, I notice a bunch of .c files being converted to .cpp! I haven't
> looked at the code itself, does it mean that these files now have
> classes / instances in them or is it the same code in a .cpp file (which
> is already a big improvement)?
>
> Jean
>
> On 9/24/23 2:26 PM, John Ralls wrote:
> > The GnuCash development team announces GnuCash 5.4, the fifth release in
> the stable 5.x series
> >
> > Between 5.3 and 5.4, the following bugfixes were accomplished:
> >
> >  Bug 728875 - Back button does not work in QIF import assistant
> >  Bug 797507 - GnuCash Splash screen may disappear before the main
> window appears
> >  Bug 798709 - Total(Period) column does not refresh period's value
> after update of the period in settings.a>
> >  Bug 798904 - GnuCash on Windows opens a CMD window at startup.
> >  Bug 798925 - Python bindings: "invalid unclassed pointer in cast to
> 'QofInstance'".
> >  Bug 798944 - Program crashes when matching transactions
> >  Bug 798950 - Bug Report: Incorrect Currency Conversion and Provider
> Invoice Payment Recording
> >  When balancing lots use the split amount, not the value
> >  Recalculate the values using deduced exchange rates after
> adjusting split amounts.
> >  Be conservative when recalculating values after breaking up a
> split to avoid imbalances caused by rounding.
> >  Bug 798958 - gncScrubLotLinks will infinite loop in some conditions
> >  Bug 798982 - GetQuotes crashes if Finance::Quote returns an empty
> date.
> >  Bug 798983 - Empty Orphan account appears after entering
> transactions in 5.3
> >  Bug 798990 - Notes No Longer Autofills
> >  Bug 798991 - Incorrect Account Name Order in Transaction Report
> >  Bug 798995 - Keystrokes ignored during ledger entry
> >  Bug 798998 - Job Report Not Working
> >  Bug 799004 - Update of Prices attaches incorrect Date
> >  Bug 799010 - gnc-register-account-sel-limited-option errors doesn't
> work
> >  Bug 799020 - widget of gnc-register-list-option disregards user's
> clicks
> >  Bug 799021 - Saved report renders default of
> gnc-register-list-option
> >  Bug 799036 - Import prices from a CSV date problem
> >  Bug 799039 - gnc:strify produces unusual results or crashes GnuCash
> when fed an option from gnc-lookup-option
> >  Bug 799048 - Hover on tab not correct
> >  Bug 799051 - Shortcut Ctrl + Tab not working in 5.3
> >  Bug 799054 - Stock Assist not functioning
> >  Bug 799060 - Consistent Crash in Invoices
> >  Bug 799068 - csv export active register not working
> >  Bug 799069 - Multicurrency Invoice Payment
> >  Bug 799075 - Saving display tab changes in Report Options does not
> work.
> >  Bug 799084 - Unable to create new scheduled transaction
> >
> > The following fixes and improvements were not associated with bug
> reports:
> >
> >  [import-main-matcher.cpp] After clicking/toggling A/U+C/C checkbox,
> reselect the row because it'll be much faster to use keyboard navigation --
> use up/down/left/right to target desired checkbox, hit  
> repeatedly to repeat the same action over several consecutive rows.
> >  Implement support for !Type:Prices records in the QIF importer.
> >  Modernize construction of GObjects using G_DECLARE_DERIVABLE,
> G_DECLARE_FINAL, etc.
> >  Fix yet more leaks.
> >  [DBI backend] Change DBI test URLs to environment variables from
> cmake configuration definitions.
> >  Restore the Stock Transaction Assistant to full operation.
> >  Fix the Fancy Date file property so that it saves.
> >  Fix formatting error in po files project-id line.
> >  [simple-business-create.py] Overwrite an existing file instead of
> crashing.
> >  Update github action package versions.
> >  Add parsing mixed number and fraction (e.g. 10 1/2) to the
> gnc_numeric string constructor.
> >  Bump minimum cmake version to 3.14 and drop some conditionals for
> older versions
> >  Major speedup in the SQLBackend by replacing C++ exceptions with
> std::optional for null values.
> >  Refresh the GUI on completion of the import matcher so that the
> imports are immediately reflected in the register.
> >  Improve online quote retrieval error reporting.
> >  Test loading and saving XML files with and without compression
> >  [import-main-matcher] always defer_bal_computation during import to
> speed up both importing new transactions, and destroying existing ones.
> >  GncGtkListUIItem::set_option_from_ui_item: Iterate over selected
> items Instead of all possible items.
> >  Convert gnc-of

Re: [GNC-dev] [GNC] GnuCash 4.900 Released

[Christopher Lam]

Note also this release will perform a one-time change to the internal
representation of budget amounts to fix a class of bugs. The budget amounts
will hopefully be more stable and reliable, and reflect the reverse
balanced accounts global preference closely.

Beta testers are needed to verify the behaviour of the budget editor and
reports.

On Tue, 10 Jan 2023, 1:03 pm John Ralls,  wrote:

> The GnuCash development team announces GnuCash 4.900, the first unstable
> release leading to GnuCash 5.0.
>
> This is an unstable release for testing purposes. Do not use it with
> production data! Make a copy of your book to test this release.
>
> New Features
>
> A new Stock Transaction Assistant to guide you through entering most
> investment transactions for stocks, bonds, and mutual funds. You can access
> it from Actions>Stock Assistant when you have the Accounts page ora Stock
> or Fund account register open.
> A new Investment Lots report showing a graph of capital gains and
> losses in a period by investment lot. Note that if you don't use the View
> Lots dialog to manage capital gains and losses this report won't have
> anything to show you. Use Reports>Assets & Liabilities>Investment Lots to
> see the report.
> A new tab on the New/Edit Account dialog called More Properties
> includes entries to set a high and low limit on an account. That's coupled
> to a new column that's available on the Accounts Page, Balance Limit. If
> you set a high or low limit and the account balance falls above or below
> the respective limit an indicator will be shown in the Balance Limit column.
> The description field quickfill in the register now displays a
> drop-down list of possible completions instead of just one inline
> completion.
> File import menu items for the MT940, MT942, and DTAUS formats is
> replaced with a single Import from AQBanking that supports importing any
> file format supported by AQBanking, including the frequently requested CAMT.
>
> Between 4.13 and 4.900, the following bugfixes were accomplished:
> The following fixes will also appear in GnuCash 4.14:
>
> Bug 798588 - sx scrubbing was using incorrect free function
> Bug 798625 - "Last up through report date" changed in 4.12
> Bug 798679 - Unicode normalization should be used for comparison but
> not stored.
> Bug 798702 - Crash in gnc_plugin_page_focus_idle_destroy() closing a
> report before it completes.
> Bug 798705 - New: UI string mismatch: OK vs. Next
> Bug 798717 - Reports > Business > Fancy Invoice duplicates company
> details
>
> The following additional bug fixes are in unstable only:
>
> Bug 403979 - Balance column shows only low order digits when too narrow
>
> If the column is too narrow to display the whole number it will
> display the leading digits with an ellipsis (…).
> Bug 769256 - Change New Account Dialog
>
> Rearrange the New and Edit Account dialog to move the parent selector
> under the description field followed by the account type as a combo (i.e.
> drop down) list.
>
> The following fixes and improvements were not associated with bug reports:
>
> Unicode normalization for string matches is changed from NFKC to NFC.
> This means that font and positional variants will no longer match and is
> unlikely to affect most users. See Unicode Normalization Forms:Canonical
> and Compatibility Equivalence for the technical details.
> The Gtk menu structure has been rewritten to use the newer
> GMenu/GMenuModel system. This change is mostly invisible to users, except
> that to keep menu accelerators (like Q to quit) working on macOS we
> had to let macOS handle the events. That will affect using cut, copy, and
> paste in dialog boxes because the menu will intercept them. That's
> temporary, we hope to have it fixed for GnuCash 4.901.
> The Finance::Quote interface is rewritten in C++. This new design will
> allow much better capture of diagnostics from Finance::Quote making
> troubleshooting problems much easier.
> The perl Finance::Quote utilities gnc-fq-check, gnc-fq-dump, and
> gnc-fq-helper are removed and new commands added to gnucash-cli: --quotes
> info replaces gnc-fq-check and --quotes dump replaces gnc-fq-dump.
>
> New API: The options system has been rewritten in C++ with Scheme wrappers
> for report options. While this is invisible to most users, those who have
> written custom reports should look for deprecation warnings when the custom
> reports are reconciled. The main difference is that option creation and
> registration is now done in a single function call. Nearly all standard
> code defined a local convenience function that wrapped the two steps, for
> example
>
> (let* ((options (gnc:new-options))
>(add-option
>  (lambda (new-option)
>   (gnc:register-option options new-option)
>
>
> called as
>
> (add-option
> (gnc:make-string-optionpagename title key docstring defa

Re: [GNC-dev] Conditions to move revamped GnuCash Mobile App to GnuCash org

[Christopher Lam]

Agree to both suggestions.

Within the mailing lists, any questions about GfA were answered by Gnucash
regulars piping "GfA is dead". The GfA community could start to offer
responses and support.

Technically, if GfA code started to work on linking with libgnucash, then I
think both communities will benefit greatly: libgnucash will be better
debugged, and GfA will never need to catch up with backend changes.

On Thu, 29 Sept 2022 at 08:17, Daniel Brown  wrote:

> Hello GnuCash devs,
>
> does someone here have (had) a relation to the gnucash-android project?
> I couldn't find a way to contact the mainter "codinguser" and the project
> is abandoned: https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices
>
> Recently there have been a couple of people (including me) who would like
> to contribute/maintain/fork/rewrite the project to keep it alive:
> https://github.com/codinguser/gnucash-android/issues/913
>
> I have started a couple of steps to revive the project and will try to
> establish a new leading fork so that all the open contributions can find
> its way into the app. And as part of this revamp I would consider aligning
> the project to gnucash.org
>
> What would be necessary, to move and continue the project under the
> gnucash org in the future?
>
> I mean not only GitHub organization, but it would would be great to see
> the project as an official part of the community, with vendor "GnuCash" in
> the app store, mailing-list for support and so on.
>
>
> Best Regards
> Daniel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] msg "Open" in gnucash/gnome/dialog-lot-viewer.c:829

[Christopher Lam]

My change was merely to reuse an existing string in the lot viewer, for its
exact same purpose.

Perhaps the original committer [1] needs to be informed?

[1]
https://github.com/Gnucash/gnucash/commit/0b37c913f053f86196f6cd6689fcaba2e08b387e

On Mon, 12 Sept 2022 at 04:53, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Christian,
>
> idid you check all other occurrences. If yes, I would like to add the
> MsgContext "Adjective" to dialog-lot-viewer.c and run a msgmerge.
>
> Regards
> Frank
>
> Am 11.09.22 um 22:05 schrieb Christian Stimming:
> > Hi Christopher,
> >
> > in gnucash/gnome/dialog-lot-viewer.c you recently added the function
> > lot_get_closing_date() which might return the translated string "Open"
> if there is no such
> > closing date because the lot is still in the status "opened".
> >
> > There's an issue with this translation string: It is super-ambiguous. In
> most contexts, a
> > translation string "Open" is used in the sense "to open [something]" but
> the string is just
> > "Open" ie the verb. Contrary to this, in this particular place the
> string should mean
> > "[something is in state] Open" but the string is also just "Open", ie
> the adjective. This won't
> > work for translators, because in almost all other languages, the verb
> and the adjective will be
> > two vastly different strings.
> >
> > The solution is to use the C_( ) macro instead of _( ) which is where
> the additional context
> > string is used.
> > https://www.gnu.org/software/gettext/manual/html_node/Contexts.html[1]
> > https://wiki.gnucash.org/wiki/Translation#Message_Context[2]
> >
> > This way, the string "Open" with no context should be used only when
> this is the verb
> > meaning ie "to open", but not for the status as it is in this file here.
> >
> > Thanks a lot!
> >
> > Regards,
> > Christian
> >
> > 
> > [1] https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
> > [2] https://wiki.gnucash.org/wiki/Translation#Message_Context
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] alpha-testing budgets in 5.x

[Christopher Lam]

On Tue, 4 Jan 2022 at 22:21, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> On 1/4/22 10:40 AM, Christopher Lam wrote:
> > Experienced Users,
> >
> > The upcoming 5.x series (master branch) currently has a one-time fix for
> > budgets to ensure they're internally stored as unreversed numbers.
> > Currently (up to 4.x) budgeting $1000 income into $600 expense and $400
> > liability repayment are stored as +1000, +600, +400. They should be
> stored
> > internally as -1000, +600, +400 amounts, as per usual accounting
> equation.
>
> I would nit-pick the assertion of 'usual accounting equation'. I've only
> seen one form of it, in any reference, and short of any further
> 'factoring' it looks like this:
>

(snip)

The internal representation for *all* GnuCash transactional data has always
(IIUC) followed the convention "asset + liability + equity + income +
expense == 0". This is what I meant by the GnuCash accounting equation.
This dictates the amounts and signs saved in the XML/SQL. This also applies
to budget amounts, except budget income amounts. This will be modified in
5.x.

Any sign reversal *for display* aims to follow the global pref "Reverse
Balanced Accounts". This is stored in
https://wiki.gnucash.org/wiki/Configuration_Locations#GSettings -- on
Windows it'll be the systemwide registry
Computer\HKEY_CURRENT_USER\SOFTWARE\GSettings\org\gnucash\GnuCash\general

HTH, C
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] alpha-testing budgets in 5.x

[Christopher Lam]

Experienced Users,

The upcoming 5.x series (master branch) currently has a one-time fix for
budgets to ensure they're internally stored as unreversed numbers.
Currently (up to 4.x) budgeting $1000 income into $600 expense and $400
liability repayment are stored as +1000, +600, +400. They should be stored
internally as -1000, +600, +400 amounts, as per usual accounting equation.
The internal numbers assume the reversal pref is "Credit Accounts". This
means the budgets are currently functioning well *only* if reversal
preference is set to credit-accounts

A obligatory one-time fix is suggested and applied on the master branch,
applying some heuristics and negating the numbers, and will render the
datafile unreadable on GnuCash prior to 3.7. It is *not* an option to make
the one-time fix optional, because this will mean maintaining two code
paths in perpetuity. However I'm not sure if it is debugged enough.

I'd like to ask experienced users to test from the master branch, either as
win32 nightlies https://code.gnucash.org/builds/win32/master/ (4-jan-2022
onwards) or building on linux, and report back of the new budget is *less*
buggy than in 4.x maint series. Please do NOT test master on your
production datafile.

If there are unsolvable bugs, then I'll suggest that the one-time fix
change must be undone, and someone else may decide to try again.

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

Re: [GNC-dev] Using WSLg for building and using Gnucash

[Christopher Lam]

I think it's a good idea to document your findings somewhere like the wiki.
Windows builds are hindered by old WebKit and maybe regular builds with WSL
gnucash can be offered.

On Fri, 22 Oct 2021, 5:13 am Sumit Bhardwaj,  wrote:

> There have been some threads here about using WSL to use and develop
> Gnucash. I wanted to report back on my experience.
>
> For the last few months, I have been using WSLg (
> https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps) to build
> Gnucash from maint and use it everyday for tracking my personal finances.
> This allows me to observe build breaks and I can ensure that Clang
> toolchain works without any issues.
>
> Pros:
> - My experience of building and using Gnucash is as straightforward as it
> can get. When there was a build break and I had some time, I was able to
> send a PR.
> - VS Code works well with source and binary on WSL. I use that for my day
> job where I develop for Windows and Linux.
> - If and when I have time, I can contribute which might be far less than
> what I hoped. ☹
>
> Cons:
> - WSLg doesn't build Windows binaries; Gnucash has to build Windows
> binaries for Windows users.
> - WSLg is only available on Windows 11.
> - WSLg is part of developer environment which might limit usage.
>
>
> Thanks,
> Sumit
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Report with Fiscal Year

[Christopher Lam]

Where is it mentioned that reports are being converted to c++?

There is currently a separation between libgnucash (eg the engine and
backend database) and gnucash (eg the UI, reports, import/export). There is
a drive to remove guile from libgnucash. This may allow libgnucash to be
used in iOS for example.

On Mon, 6 Sept 2021 at 08:55, flywire  wrote:

> I recall recent discussion about separating the main app and reporting.
> App, database and reporting modules seem to offer a lot of scope for
> non-traditional integrations I've raised before. One of my repos uses ocr
> to load bank statements, and there's an ever-expanding range of smart
> analysis tools.
>
> I'm concerned John's described pulling report functionality back into c++.
>
> It's a while since I worked as a programmer but I've been involved in a
> broad range of system development. I was after a c++ developer a couple of
> years ago and a university lecturer told me they'd stopped teaching it a
> few years earlier. He said to concentrate on the functionality and let the
> implementation move with the technology. M a y b e  GnuCash is. The
> application doesn't need to run on 1990 technology anymore.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Report with Fiscal Year

[Christopher Lam]

> How much time would it take to fix the code and not have to change the
> dates annually?


https://github.com/Gnucash/gnucash/pull/459


> Can I save time and effort by changing the code?
> Incidentally to the problem, how much will I learn for the future about
> the code?
>

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

Re: [GNC-dev] Removing "unused" code

[Christopher Lam]

This particular commit aimed to simplify and reduce old code. It can be
reverted.
Would you consider submitting them into the repository?

On Fri, 11 Jun 2021 at 06:12, Mike Alexander  wrote:

> I would like to request that we avoid removing code that is thought to
> be unused, but which may in fact be used, just for the sake of cleaning
> things up.  I use a couple of reports that are not part of the standard
> GnuCash distribution and every now and then they stop working because
> something they depend on is gone.  Since some of these are reports I
> didn't write it's often a nuisance to fix them.
>
> In particular I like the EGuile budget report written by Benoit
> Blancard, et al.  It stopped working after commit 4e38b68 which removed
> a number of parameters from gnc:html-acct-table including account-name
> which this report uses.  Assuming something is unused everywhere just
> because no built-in report uses it is not a safe assumption.
>
> Rather than try to figure out what to use instead and how to fix it I
> just reverted that change, but this may cause me trouble later if
> something else is done that depends on this change.
>
> I understand that cleaning up code and removing dead code are good
> things to do, but I think this is going too far.
>
> Mike
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] New price source

[Christopher Lam]

To casual and regular users:
In addition to pricedb-nearest and pricedb-latest, there'll be a new price
source 'pricedb-nearest-before' in 4.6 onwards; this will ignore prices
*after* the report date.
e.g. a user records weekly prices e.g. on 19-dec, 26-dec, 2-jan, 9-jan etc
and runs the balance sheet report dated 31-dec.
Although the nearest price is 2-jan, we'd usually want the 26-dec price
instead (e.g. a stock-split, or a GFC may have occurred on 1-jan).
Please test and report -- recent builds 24 April 2021 onwards have this new
source.
https://code.gnucash.org/builds/flatpak/maint/ and
https://code.gnucash.org/builds/win32/maint/
Relevant bug report: https://bugs.gnucash.org/show_bug.cgi?id=743753
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Reports: Help normalizing a list of gnc:monetary values

[Christopher Lam]

On Wed, 31 Mar 2021 at 15:32, Evelyn Yamanaka 
wrote:

> Thank you so much, Christopher!
>

You're welcome!

So, the normalization / percentage representation is actually part of
> a report I'm working on whose primary goal is to support some concept
> of tagging / grouping for accounts that's independent of the account
> tree structure. I have a working version up if you or anyone is
> curious:
>
> https://github.com/ritsu/gnucash-reports
>
> Any comments or suggestions would be appreciated, especially since I'm
> definitely not a scheme coder. ;) I've tried to leave as much of the
> original category-barchart.scm untouched as possible, and marked the
> places I've changed with a "Tags:" prefixed comment.
>

I had a quick glance at the code; with one serious feedback:

You're very much wrong, you're a very competent schemer. The structure is
fine; there are some tiny optimisations possible, but overall it's very
much clean.

Note: watch out for deprecation warnings -- run with the following to
expand them.
Do ask feedback anytime.
$ GUILE_WARN_DEPRECATED=detailed ./gnucash
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Reports: Help normalizing a list of gnc:monetary values

[Christopher Lam]

Hi, the simple answer is gnc:monetary/ would divide two monetary amounts
and the result is not a monetary but a simple ratio.

(define (gnc:monetary/ a b)
 (/ (gnc:gnc-monetary-amount a)
(gnc:gnc-monetary-amount b)))

This would do the trick. Afterwards, for the chart amounts you can use the
unit-less ratio directly. Do feel free to attach your work and we'll help
you complete it.

On Mon, 29 Mar 2021, 8:00 pm Evelyn Yamanaka, 
wrote:

> I'm trying to create a stacked bar chart graph where the total for
> each period on the x-axis is 100%, so you can easily see trends in
> changes in the proportion of individual accounts relative to the
> total.
>
> I'm using category-barchart.scm as a starting point, where account
> balances are stored as a list of pairs ( ) in
> the variable all-data, and  is a list of gnc:monetary
> values (or something like that?) for each period on the x-axis.
>
> I can get totals for each period with:
>
> (let ((totals
> (map
>   (lambda (l) (apply gnc:monetary+ l))
>   (apply zip (map cadr all-data)
>   (set! all-data-totals (list "Total" totals)))
>
> However, I'm not sure how to divide gnc:monetary values by other
> gnc:monetary values. I know I can add with:
>
> (for-each
>   (lambda (d)
> (let ((new-data (map gnc:monetary+ (cadr d) (cadr d
>   (set! all-data-new
> (append all-data-new
> (list (car d) new-data)
>   all-data)
>
> But I'm not sure how to divide. Something like:
>   (map gnc:monetary/ (cadr all-data-totals) (cadr d))
>
> Of course, "gnc:monetary/" is undefined, and simply using "/" does not
> work either. Is there any way to do this? Any help would be appreciated.
>
> Thanks,
> E
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GncCombott Widget

[Christopher Lam]

Hi Robert

The reality is that you're probably the most skilled in gtk in here so your
view is likely the best one. However I agree that replicating gtkcombobox
is probably unnecessary.

My personal view is that tooltips are an obscure mechanism to display
additional (occasionally crucial) useful information, and it'd be much
simpler to show it in a regular gtk label -- see example in the
reconciliation dialog, eg the reconciliation date is in the future. Or the
payment dialog whereby the invoice isn't selected, thereby creating an
unattached payment.

C


On Tue, 16 Feb 2021, 7:11 pm Robert Fewell, <14ubo...@gmail.com> wrote:

> Hi,
>
> In bug 798109 it was highlighted that the widget I wrote back in 2012 does
> not respond to keyboard use well which I think would be relatively easy to
> fix and maybe a couple of tweaks.
>
> Geert suggested that it could be dropped in favour of a traditional
> GtkComboBox.
>
> The reason I wrote it was to match the GTK2 version at that time which
> allowed you to have tooltips on the popped up menu items as well as when
> the item was selected and the popup removed. This can not be done in the
> GTK3 version as I can see no way of getting to the used GtkMenu. The GTK3
> version only supports a tooltip when there is no popup displayed. This
> tooltip can still be specific to the selected item with the use of a
> 'query-tooltip' call back.
>
> I think the widget is mainly used in dialog options for reports.
>
> I am fine with fixing the widget or replacing it, just asking if there is a
> preference.
>
> Regards,
> Bob
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 4.4 tests failing

[Christopher Lam]

Maybe this fixes it.
https://github.com/Gnucash/gnucash/commit/ffa2f606e38c96a64cbebd4204f3795d5dd7c22d

On Fri, 5 Feb 2021 at 10:05, Manfred Usselmann  wrote:

> Hi,
>
> I'm still trying to provide a GC 4.4 package for Void Linux.
>
> I have either fixed or disabled the tests mentioned below, so this is
> solved.
>
> Now I get a strange failure with  31 - test-engine. See attached log. It
> only fails on x86_64-musl!
>
> See also
> https://github.com/void-linux/void-packages/actions/runs/538777398
>
> https://github.com/void-linux/void-packages/pull/27504/
>
> Any idea what could cause this?
>
> Thanks and regards
> Manfred
>
>
> Am 03.01.2021 18:18, schrieb John Ralls:
> >> On Jan 3, 2021, at 5:12 AM, Manfred Usselmann 
> >> wrote:
> >>
> >> Hi,
> >>
> >> I'm building GnuCash 4.4 for Void Linux. The build itself is
> >> successful and GC seems to run ok, but when I run the test suite with
> >> the released code some test do fail:
> >>
> >>96% tests passed, 4 tests failed out of 111
> >>
> >>The following tests FAILED:
> >> 31 - test-qof (Subprocess aborted)
> >> 54 - test-gnc-numeric (Failed)
> >> 55 - test-gnc-timezone (Failed)
> >> 56 - test-gnc-datetime (Failed)
> >>
> >> For details see attached log. Can this be ignored and the package
> >> released despite of these failed tests?
> >
> > The failures appear to be down to your not having the fr_FR and de_DE
> > locales installed and to not having time zone info support. The
> > locales are needed only for testing, but if TZ info is an optional
> > package on Void Linux then it should be added as a package dependency.
> > If TZ info is installed and GnuCash can't find it then you need to
> > figure out exactly what's going wrong.
> >
> > Regards,
> > John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] UK specific: MTD - Making Tax Digital

[Christopher Lam]

Hello you're very welcome to submit a pull request. Any code will obviously
be GPL.

Please don't hesitate to contact us if you have any questions.

On Thu, 14 Jan 2021, 5:26 pm chr...@floatdene.com, 
wrote:

> Hi,
>
> Is anyone interest in having a MTD bridge for GnuCash for VAT submissions?
> I
> have developed a bridge and would be happy to integrate it with GnuCash if
> there is still any interest.
>
> Kind regards,
> Chris
>
>
>
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] build stats/badges for GNC maint, 3.6, 3.5 using Docker

[Christopher Lam]

Dale, your work will definitely be a candidate for inclusion if you do a
PR. A private repository doesn't necessarily give any confidence that its
use can be considered suitable for everyone's use.

As such my particular wishes are to:
- a dev environment with latest packages
- a dev environment with earliest supported packages

All for hacking and building on Linux. I'm not building on windows, nor for
windows. But if the Docker files were present in project root, then they'd
be readily used.

Thanks for the work!


On Wed, 9 Dec 2020, 1:54 am Dale Phurrough,  wrote:

> Hi, John. Still not building official releases in containers? Give
> in...they're reproducible, self-documenting, easy to version control, etc.
> You can use them for building, CI, test. They run on clouds, single
> machines, and personal laptops.
> All one. All the same.
>
> I do have a Windows Dockerfile that is about 80% complete. I also have a
> few local updates on it that I haven't pushed. You and..I forget their
> name...helped me make progress when I found bugs in your gnucash Windows
> build process. Changing to use a Windows Dockerfile, you won't have these
> "where is msys2" questions. Because it will be exactly where you put it
> given the commands in the Dockerfile. You are no longer tied to the setup
> of some pipeline's vm. And, if you want to switch between CI pipelines
> (github, appveyor, circleci, travis, your laptop, etc.) there is no change
> within the Dockerfile. This is a significant save of manpower...or should
> we say personpower.
>
> Check my repo link I provided for setup documentation, and both the Linux
> and Windows Dockerfiles. My Linux Dockerfiles work across a broader set of
> distributions than yours. The ones in your repo were updated after I
> published mine but still narrow. I continue to recommend there be only one
> set, we collaborate, and they be used for build, ci, test, everything.
> Otherwise, the apps you distribute are different from the apps you test -->
> which somewhat invalidates the automated testing.
>
> Of course, the core team can do whatever you want as you are in control of
> official distributions, FOSS ethos, we all do our own thing, etc. No
> worries, no problems, no regrets, all is good. :-)
> I'll support someone if they want to evolve the work I've done. I am more
> motivated to help when I see my effort is incorporated into projects and
> helps the broadest set of people.
>
> --Dale
>
> On Tue, Dec 8, 2020 at 5:55 PM John Ralls  wrote:
>
>> Dale,
>>
>> We already have dockers running Linux--Arch Linux, Ubuntu-18.04, and
>> Ubuntu-20.04--on Travis CI and Github actions. Feel free to borrow whatever
>> you need from there to update yours, the docker files are in utils/ci.
>>
>> Chris isn't looking for CI, he wants a Windows Docker image with all the
>> dependencies set up as a shortcut to using gnucash-on-windows to create a
>> build environment.
>>
>> On the other hand *I* want to get a Github action for Windows CI set up
>> but I'm stuck on accessing MSYS2.
>> https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md
>> says that Mingw-w64 is preinstalled but doesn't provide any information on
>> where. Do you know?
>>
>> Regards,
>> John Ralls
>>
>>
>> > On Dec 8, 2020, at 8:01 AM, Dale Phurrough via gnucash-devel <
>> gnucash-devel@gnucash.org> wrote:
>> >
>> > If Linux builds only, then only two things needs to be done:
>> >
>> >   1. Update the existing 3.x solution at
>> >   https://github.com/diablodale/gnucash-dev-docker to compile for
>> GnuCash
>> >   4.x. After someone understands the shared/common methodology, this is
>> less
>> >   than a week of work. A single platform (e.g. Debian/Ubuntu) might
>> even be
>> >   in hours.
>> >   2. Copy the documentation I wrote at that same repo and integrate it
>> >   into GnuCash docs -- adapting it for any stylistic changes. This is
>> less
>> >   than a day of work if someone understands GnuCash doc process.
>> >
>> >
>> > On Tue, Dec 8, 2020 at 3:08 PM Christopher Lam <
>> christopher@gmail.com>
>> > wrote:
>> >
>> >> Sounds all complex... A simple Dockerfile to set up a dev environment
>> >> would be a good start! Or, if it already exists, documentation could be
>> >> improved - "how to start hacking and building after a bare-bones
>> >> linux+docker install".
>> >>
>> >> On Tue, 8 Dec 2020 at 13:00, Dale

Re: [GNC-dev] build stats/badges for GNC maint, 3.6, 3.5 using Docker

[Christopher Lam]

Sounds all complex... A simple Dockerfile to set up a dev environment would
be a good start! Or, if it already exists, documentation could be improved
- "how to start hacking and building after a bare-bones linux+docker
install".

On Tue, 8 Dec 2020 at 13:00, Dale Phurrough  wrote:

> Hi. Anything is possible. ;-)
>
> Regarding Dockerfiles to build Gnucash for Linux, Windows, and Osx...
>
>- Gnucash 4.x has several dependency changes and I don't have a
>dockerfile to build them.
>- Linux updates will be relatively straightforward. It is usually only
>differences in dependencies on the four Linux forks (arch, debian, rhel,
>suse)
>- Windows build needs some work. I was about a week away from having a
>full clean build. I partnered with the core gnucash team to have several
>issues fixed in the windows build script/process -- issues unrelated to
>Docker. More work is needed to make the build consistent, smooth and easy
>to automate. The types of issues found/fixed were, e.g.: only works in a
>specific directory or specific build machine, custom scripts not part of
>the source code, etc.
>- Osx is not directly possible. There is no mechanism for the OS
>directly inside a Docker container to be Osx. You could have the Docker
>container be Linux and within that install a full virtualizer like
>virtualbox and within that virtualbox vm install Osx. I am not a lawyer and
>I am not aware of the legality of using Osx in this way. There are also
>cross-compilers -- using a compiler on Linux to build an Osx binary.
>Unclear if this would be a reliable binary. Unclear how to test the binary
>built.
>
> Here are a few things to consider regarding build/test pipelines:
>
>- Azure Pipeline isn't worth the trouble
>- Appveyor works generally well. It is the most capable for
>cross-platform building.
>- Github actions is a mix of the two. It has linux, win, and macos
>build environments...but doesn't support docker on all of them.
>- Github actions should work to build/test all Linux GnuCash
>versions.
>- Github actions does not (yet) support Windows Docker containers.
>This is because the Github runners for Windows do not (yet) support running
>Windows containers within them. See github action docs and
>https://github.com/actions/virtual-environments/issues/1143
>- Github actions is only "preview" for Mac. Issues will arise due to
>the host itself and the gnucash build process.
>- If you want to use Github actions to build Windows and Osx, you
>can't do it today with a Dockerfile. It can only be done by running the
>build directly on their VM not using Docker.
>
> I have the knowledge to do this work, but I don't currently have the
> bandwidth. I have this topic area and GnuCash reconciliation in my "queue";
> currently slotted for Feb/March 2021.
> An alternative...I could support someone. Sumit Bhardwaj expressed
> interest.
>
> --Dale
>
>
> On Sun, Dec 6, 2020 at 3:03 AM Christopher Lam 
> wrote:
>
>> Hi Dale
>> Docker is now firmly entrenched in the industry; would you be able to
>> create a PR to set up the Dockerfile in the project root (or /util), and
>> add a few notes in the wiki to help complete docker newbies? e.g.
>> - how to set up a dev environment
>> - automate build and install
>> You may be aware we're moving away from travis to github actions.
>> C
>>
>> On Wed, 17 Jul 2019 at 18:40, Dale Phurrough via gnucash-devel <
>> gnucash-devel@gnucash.org> wrote:
>>
>>> Hi all. I finished the second stage of my project to automate build/test
>>> of
>>> GnuCash with Docker. See the badges, drill down to logs and individual
>>> test
>>> results at
>>> https://diablodale.github.io/gnucash-dev-docker/
>>>
>>> In previous emails you read about the easy consistent GnuCash build/test
>>> with Docker.
>>> https://github.com/diablodale/gnucash-dev-docker
>>>
>>>- Updated with clearer categorized build dependencies in Dockerfiles
>>>- Used these Docker containers to build/test across 14
>>> distrib/versions
>>>of Linux
>>>- Containers can be built locally or downloaded from DockerHub
>>>- Automated build and tests using these containers via CI on AppVeyor
>>>- Transformed ctest results through XSLT to JUnit format
>>>- Exposed build and test results to badges
>>>
>>> Still to do
>>>
>>>- Microsoft Azure CI Pipelines offers a free tier of CI 

Re: [GNC-dev] build stats/badges for GNC maint, 3.6, 3.5 using Docker

[Christopher Lam]

Hi Dale
Docker is now firmly entrenched in the industry; would you be able to
create a PR to set up the Dockerfile in the project root (or /util), and
add a few notes in the wiki to help complete docker newbies? e.g.
- how to set up a dev environment
- automate build and install
You may be aware we're moving away from travis to github actions.
C

On Wed, 17 Jul 2019 at 18:40, Dale Phurrough via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Hi all. I finished the second stage of my project to automate build/test of
> GnuCash with Docker. See the badges, drill down to logs and individual test
> results at
> https://diablodale.github.io/gnucash-dev-docker/
>
> In previous emails you read about the easy consistent GnuCash build/test
> with Docker.
> https://github.com/diablodale/gnucash-dev-docker
>
>- Updated with clearer categorized build dependencies in Dockerfiles
>- Used these Docker containers to build/test across 14 distrib/versions
>of Linux
>- Containers can be built locally or downloaded from DockerHub
>- Automated build and tests using these containers via CI on AppVeyor
>- Transformed ctest results through XSLT to JUnit format
>- Exposed build and test results to badges
>
> Still to do
>
>- Microsoft Azure CI Pipelines offers a free tier of CI that could be
>used and 10x faster. I will explore their offering to see if it meets
> needs
>- Windows builds. Thanks to JohnR and GeertJ, good progress has been
>made. I have the responsibility for next steps. I need to return to my
>testing to see what is missing or not functioning.
>- Watch and evaluate AppVeyor. I exposed several bugs in the AppVeyor
>offering as well as some limitations that required workarounds. I've
>reported the issues to the AppVeyor team.
>- Evaluate a switch to this docker build/test for GitHub PR testing. The
>existing Travis process being used has aged and doesn't test a full
> suite
>of functionality. With experience using AppVeyor and/or Microsoft CI,
> the
>core GnuCash team can evaluate switching away from the old Travis
> method.
>- Any related requests? Please send them to me.
>
> --Dale
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Fwd: Broken: Gnucash/gnucash#6802 (maint - ccc6531)

[Christopher Lam]

Timezone error again... I can reproduce when running via "TZ=UTC-8 ninja
check"

113: Test command: /usr/bin/python3
"/home/chris/sources/gnucash/maint/bindings/python/tests/runTests.py.in"
113: Environment variables:
113:  GNC_BUILDDIR=/home/chris/sources/gnucash/maint-build
113:
 
PYTHONPATH=/home/chris/sources/gnucash/maint-build/lib/python3.8/site-packages:/home/chris/sources/gnucash/maint-build/lib/gnucash:/home/chris/sources/gnucash/maint-build/common/test-core
113: Test timeout computed to be: 1000
113:
F./home/chris/sources/gnucash/maint/bindings/python/tests/test_session.py:26:
DeprecationWarning: Use of ignore_lock, is_new or force_new arguments is
deprecated. Use mode argument instead. Have a look at
gnucash.SessionOpenMode.
113:   self.ses = Session(ignore_lock=False, is_new=True, force_new=False)
113:
../home/chris/sources/gnucash/maint/bindings/python/tests/test_session.py:52:
DeprecationWarning: Use of ignore_lock, is_new or force_new arguments is
deprecated. Use mode argument instead. Have a look at
gnucash.SessionOpenMode.
113:   ses.begin(uri, is_new=False)
113:
/home/chris/sources/gnucash/maint/bindings/python/tests/test_session.py:61:
DeprecationWarning: Use of ignore_lock, is_new or force_new arguments is
deprecated. Use mode argument instead. Have a look at
gnucash.SessionOpenMode.
113:   ses.begin(uri, is_new=True)
113: ..* 04:49:37 ERROR  [xaccTransScrubSplits()] Transaction
doesn't have a currency!
113: * 04:49:37 ERROR 
[xaccScrubUtilityGetOrMakeAccount()] No currency specified!
113: .
113: ==
113: FAIL: test_post (test_business.TestBusiness)
113: --
113: Traceback (most recent call last):
113:   File
"/home/chris/sources/gnucash/maint/bindings/python/tests/test_business.py",
line 66, in test_post
113: self.assertEqual(neutral_time,
113: AssertionError: datetime.datetime(2020, 11, 1, 10, 59,
tzinfo=datetime.timezone.utc) != datetime.datetime(2020, 10, 31, 18, 59,
tzinfo=datetime.timezone.utc)
113:
113: --
113: Ran 55 tests in 0.777s
113:
113: FAILED (failures=1)

-- Forwarded message -
From: Travis CI 
Date: Sun, 1 Nov 2020 at 13:22
Subject: Broken: Gnucash/gnucash#6802 (maint - ccc6531)
To: 


Gnucash

/

gnucash
<https://travis-ci.org/github/Gnucash/gnucash?utm_medium=notification&utm_source=email>

[image: branch icon]maint <https://github.com/Gnucash/gnucash/tree/maint>
[image: build has failed]
Build #6802 was broken
<https://travis-ci.org/github/Gnucash/gnucash/builds/740595807?utm_medium=notification&utm_source=email>
[image: arrow to build time]
[image: clock icon]17 mins and 10 secs

[image: Christopher Lam avatar]Christopher Lam
ccc6531 CHANGESET →
<https://github.com/Gnucash/gnucash/compare/e9d1e694f29a...ccc653186c11>

[dialog-tax-table.c] free GList after use

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build
environment updates? We set up a mailing list for you!
SIGN UP HERE <http://eepurl.com/9OCsP>

[image: book icon]

Documentation <https://docs.travis-ci.com/> about Travis CI
Have any questions? We're here to help. 
Unsubscribe
<https://travis-ci.org/account/preferences/unsubscribe?repository=831607&utm_medium=notification&utm_source=email>
from build emails from the Gnucash/gnucash repository.
To unsubscribe from *all* build emails, please update your settings
<https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email>.

[image: black and white travis ci logo] <https://travis-ci.com>

Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy Jacops
| Contact: cont...@travis-ci.com | Amtsgericht Charlottenburg, Berlin, HRB
140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: DE282002648
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Auto reconcile from register window

[Christopher Lam]

I see no objections myself.

Auto-clear will have increased test coverage[1] and visibility, and I have
a plan to modify so that the hash-table is generated once as soon as the
dialog is created, saved within the dialog, and updated when the end_value
is changed. Thus the user could have live feedback whenever a valid
autoclear target is entered. The algorithm can also be improved to clear
even when splits have duplicate amounts, see PR[1].

[1] https://github.com/Gnucash/gnucash/pull/805

On Wed, 28 Oct 2020, 2:03 pm Mike Alexander,  wrote:

> Yes, but, Autoclear doesn't need an account any more than reconcile
> needs one.  Both gnc_plugin_page_register_cmd_reconcile and
> gnc_plugin_page_register_cmd_autoclear call
> gnc_plugin_page_register_get_account to get the account to work on.
> This may return a null pointer if the register doesn't have a clearly
> defined account (e.g. search results), but it works as well for one
> caller as for the other.  Reconcile calls recnWindow to do the real work
> and it checks for a null account and returns immediately if given one.
> The corresponding autoclear method is autoClearWindow and it doesn't
> check for a null account pointer.
>
> It seems to me that if we fix autoClearWindow to check for a null
> account and hook up the menu item in the register window things should
> work fine.  I can do that unless someone knows why it's a bad idea.
>
> Mike
>
> On 26 Oct 2020, at 2:49, Christopher Lam wrote:
>
> > Having said that, when we type into the blank entry it knows which
> > account to tie the split to... So, the account could be found
> > somewhere...
> >
> > On Mon, 26 Oct 2020, 2:38 pm Christopher Lam,
> >  wrote:
> > From my understanding, this code is not hooked up to the register
> > because: a register is always a search list, and not necessarily tied
> > to an account. Proof: the blank transaction register entry has no
> > account.
> >
> > I gather the original coder noticed the same, therefore didn't hook
> > it.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Auto reconcile from register window

[Christopher Lam]

Having said that, when we type into the blank entry it knows which account
to tie the split to... So, the account could be found somewhere...

On Mon, 26 Oct 2020, 2:38 pm Christopher Lam, 
wrote:

> From my understanding, this code is not hooked up to the register because:
> a register is always a search list, and not necessarily tied to an account.
> Proof: the blank transaction register entry has no account.
>
> I gather the original coder noticed the same, therefore didn't hook it.
>
> On Mon, 26 Oct 2020, 2:10 pm Mike Alexander,  wrote:
>
>> I noticed the recent checkins related to the auto reconcile feature.
>> This intrigued me since I didn't know such a feature existed.  After
>> looking around for a while it appears that this is because it is only
>> available for the account tree and I always start a reconcile from the
>> register window.  Code exists in gnc-plugin-page-register.c to implement
>> it, but there isn't anything in gnc-plugin-page-register-ui.xml to
>> create the menu entry to invoke it.  I presume this is an oversight, or
>> is there some reason this shouldn't be hooked up?  Or am I missing
>> something obvious?  The same thing applies to
>> gnc-plugin-page-register2-ui.xml.
>>
>> Mike
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Auto reconcile from register window

[Christopher Lam]

>From my understanding, this code is not hooked up to the register because:
a register is always a search list, and not necessarily tied to an account.
Proof: the blank transaction register entry has no account.

I gather the original coder noticed the same, therefore didn't hook it.

On Mon, 26 Oct 2020, 2:10 pm Mike Alexander,  wrote:

> I noticed the recent checkins related to the auto reconcile feature.
> This intrigued me since I didn't know such a feature existed.  After
> looking around for a while it appears that this is because it is only
> available for the account tree and I always start a reconcile from the
> register window.  Code exists in gnc-plugin-page-register.c to implement
> it, but there isn't anything in gnc-plugin-page-register-ui.xml to
> create the menu entry to invoke it.  I presume this is an oversight, or
> is there some reason this shouldn't be hooked up?  Or am I missing
> something obvious?  The same thing applies to
> gnc-plugin-page-register2-ui.xml.
>
> Mike
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Account > Auto-Clear

[Christopher Lam]

Dear Devel,

After using GnuCash for years, I've recently discovered the interesting
Account Auto-clear facility. Consider a well-used bank account, with
numerous Reconciled "r" splits, and some recent Unreconciled "n" splits
whose amounts are as follows:

Reconciled Balance = 1000.00
Unreconciled amounts -10.00, 2500.00, -33.30, -45.00

The user checks the online bank statement, finds the current balance
currently $3456.70, corresponding to the first 3 splits being processed by
the bank, and the last transaction pending. Auto-clear will accept 3456.70
and will set relevant splits to "c" cleared. But It cannot handle the
following scenarios:
1) number of uncleared splits too high -- due to NP-hard problem, I find
the limit around 20 uncleared splits
2) more than 1 possible solution eg.
Reconciled balance 1000.00
Unreconciled amounts -10.00, 2500.00, -33.30, -10.00, -45.00

If auto-clear balance is 3456.70, there are now TWO possibilities
corresponding to the two distinct -10.00 splits. It'll abort. If auto-clear
balance is 3500.00 then it will succeed because there's only one solution
(the 2500.00 split).

I have a pending PR to optimize this functions, as well as plug some memory
leaks at https://github.com/Gnucash/gnucash/pull/797; I'll push to my beta
branch and hopefully some beta-testers will confirm that the function still
works well.

Beta testers may use my PR or the flatpak build from today onwards:
https://code.gnucash.org/builds/flatpak/christopherlam/beta/

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

Re: [GNC-dev] Cookbooks

[Christopher Lam]

https://wiki.gnucash.org/wiki/Quickstart_Australian_BAS

Other recipes are always welcome. Frank will hopefully increase visibility
:)

On Tue, 29 Sep 2020 at 00:29, Christopher Lam 
wrote:

> That's right, I forgot. For that matter I'd modified the Income&GST
> Statement report to include variants for UK-VAT (Box 1-9) and AU-BAS which
> tallies only G1 1A and 1B exclusively. Will modify prior to publish...
>
> On Mon, 28 Sep 2020 at 21:52, Liz Dodd  wrote:
>
>> On Mon, 28 Sep 2020 12:05:42 +
>> Christopher Lam  wrote:
>>
>> > Devel,
>> > Is there a suitable place where we could direct users to use recipes
>> > to get going quickly?
>> > See draft, attached.
>>
>> Chris, the ATO asks for your option 2, with gross sales etc. I always
>> do my form with option 1, and it appears that so long as I pay the
>> money, they don't mind.
>>
>> Liz
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Cookbooks

[Christopher Lam]

That's right, I forgot. For that matter I'd modified the Income&GST
Statement report to include variants for UK-VAT (Box 1-9) and AU-BAS which
tallies only G1 1A and 1B exclusively. Will modify prior to publish...

On Mon, 28 Sep 2020 at 21:52, Liz Dodd  wrote:

> On Mon, 28 Sep 2020 12:05:42 +0000
> Christopher Lam  wrote:
>
> > Devel,
> > Is there a suitable place where we could direct users to use recipes
> > to get going quickly?
> > See draft, attached.
>
> Chris, the ATO asks for your option 2, with gross sales etc. I always
> do my form with option 1, and it appears that so long as I pay the
> money, they don't mind.
>
> Liz
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Cookbooks

[Christopher Lam]

I'm not convinced the generic Guide is an appropriate location for such
country-specific recipes. The wiki is fine but has poor organisation.

Hence my original query above.

Contrast: https://beancount.github.io/docs/

On Mon, 28 Sep 2020 at 13:52, David Carlson 
wrote:

> Perhaps it would be better to format it as an appendix with reference(s) in
> appropriate places in the body of the Guide.  This would allow more detail
> for those who are interested without boring those who do not need the
> information.
>
> On Mon, Sep 28, 2020 at 8:36 AM D. via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
>
> > I agree with Frank's suggestions. The Guide would be the best spot
> > (probably in the Business Setup area of chapter 13). And you do need to
> > expand abbreviations at the first instance.
> >
> > From an editorial perspective, I think a little more explanatory
> > background would help users understand the purpose here. Also, full
> account
> > hierarchies are important (unless the GST account is a top level
> account?).
> >
> > David T.
> >
> >
> >  Original Message 
> > From: "Frank H. Ellenberger" 
> > Sent: Mon Sep 28 09:20:21 EDT 2020
> > To: Christopher Lam 
> > Cc: gnucash-devel 
> > Subject: Re: [GNC-dev] Cookbooks
> >
> > Hi Chris,
> >
> > in theory the Guide is the right place, but if you think it still needs
> > improvement, you can put it in the wiki.
> >
> > Note on your draft: Abbreviations should be defined on the first usage
> > or, if they are used in different places in the glossary and linked from
> > the first occurrence in each page.
> >
> > Regards
> > Frank
> >
> > Am 28.09.20 um 14:05 schrieb Christopher Lam:
> > > Devel,
> > > Is there a suitable place where we could direct users to use recipes to
> > get
> > > going quickly?
> > > See draft, attached.
> >
> > >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>
> --
> David Carlson
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Tabs Behaviors in GNC4.1

[Christopher Lam]

A small note about code progress (and occasional regressions). Development
takes place mainly via github and IRC; I'd wager most subscribers to devel
*will* have enough understanding to understand the ongoing discussions and
changes. Even if they have little coding skills, the commit messages will
almost always contain adequate detail regarding changes. Commit messages
are generated and distributed live to any subscriber at
https://lists.gnucash.org/mailman/listinfo/gnucash-changes

On Wed, 16 Sep 2020 at 19:47, David Carlson 
wrote:

> Geert,
>
> I believe some users have backed off of trying to express informed opinions
> about program development or documentation development because of various
> roadblocks that have been thrown up.  Sometimes we are ignored, sometimes
> asked to learn obscure new skills, and occasionally chastised for waiting
> until after the fact to 'complain', to name a few.
>
> There is a gap that we are having a hard time trying to deal with.  I don't
> know if there would be a way to 'warn' users about pending changes before
> they are released.  Some programs put changes into an official beta release
> available to the general public some time before moving to the stable
> release. Just an idea.
>
>
> On Wed, Sep 16, 2020 at 2:26 PM Geert Janssens  >
> wrote:
>
> > Op woensdag 16 september 2020 14:46:58 CEST schreef D.:
> >
> > > Thanks for pointing this bug out.
> >
> > >
> >
> > > It's too bad that the suggestion in the bug to discuss this change on
> the
> >
> > > lists was not apparently taken up. The devs would then have at least
> > heard
> >
> > > from some other users about their use cases and preferences, and users
> >
> > > would have had a heads up about the change. Instead, a change gets
> pushed
> >
> > > out based on one person's request, mainly because it involves "three
> > lines
> >
> > > of code." I'll set aside the wisdom of making changes to software based
> >
> > > primarily on the complexity of the fix, or on a single user and the
> >
> > > opinions of three devs...
> >
> > >
> >
> > > While it might seem overkill to discuss something as seemingly minor as
> > this
> >
> > > change, I think *any* change in the user interface should be discussed
> >
> > > more, rather than less.
> >
> >
> >
> > David,
> >
> >
> >
> > Yes, more discussion up front is useful. However if you want more
> > discussion to happen (or more precisely if *you* want to be get involved
> > more in such discussions) I suggest you actively choose to become more
> > involved proactively rather than waiting until a finished release is
> > presented to you. That doesn't mean you have to write or review code, but
> > you can subscribe to the channels where the devs generally communicate to
> > get an early idea of what lives there.
> >
> >
> >
> > Some topics will be brought to the users, others not so much. And by the
> > way, I don't think gnucash-user is the proper channel for this kind of
> > discussion. I believe it should be held on gnucash-devel.
> >
> >
> >
> > >
> >
> > > Now, we get to have that discussion.
> >
> > >
> >
> > > At the risk of repeating myself, let me re-present. In my usage of
> > Gnucash,
> >
> > > I keep a core set of tabs always open. These tabs represent my primary
> >
> > > active accounts: my checking account, savings account, credit card
> > account,
> >
> > > and a cash account.
> >
> > >
> >
> > > I leave them open because they are involved in the vast majority of my
> >
> > > transactions, and it is easier to click on one of the tabs than to go
> to
> >
> > > the CoA, locate the account, and open it. I like to have them at the
> top
> > of
> >
> > > the list at all times because I can quickly locate them there. I know
> > where
> >
> > > they are.
> >
> > >
> >
> > > With the latest change, I no longer can rely on this. My core tabs move
> >
> > > down. If I open one of my more obscure accounts to look at things, it
> >
> > > pushes its way in at the top. If I've opened several of them, they are
> > all
> >
> > > at the top, and when I am done with those tabs, I have to carefully
> close
> >
> > > tabs, rather than close all tabs below a certain point on the screen.
> >
> > >
> >
> > While I see what you mean with closing, I perceive this as a minor
> > behavioural change. As all the new tabs will be on top, it should not be
> > too hard to close them one by one by starting with the first one. You
> don't
> > have to move your mouse for that. I can imagine you have to be a little
> bit
> > more careful to stop clicking in time to avoid closing your first
> > "always-open" tab. However if you have many always-open tabs that problem
> > also exists when new tabs open at the end.
> >
> >
> >
> > > None of this is particularly catastrophic, but it does affect me and my
> >
> > > workflow every time I open or close an account, so I would prefer to
> have
> >
> > > the option of restoring the old tab behavior.
> >
> > >
> >
> > See my other replies here and on the

Re: [GNC-dev] [GNC] Experimental Balance Sheet report

[Christopher Lam]

Hi David, responses inline. I'm sure you know it's my work, and I am (for
now) happy to defend its state. TBH I do not need this report myself, but
figure out it fills a gap. I also think devel is more appropriate.

In my view it won't come out of experimental anytime soon because of
https://bugs.gnucash.org/show_bug.cgi?id=797786 -- figuring out price from
stock/foreign-currency into target currency is *HARD*. TL;DR: in some
price-sources (avg-bal/wt-avg) current balance sheet will tally only txns
UPTO report-date and calculate price from it; in multicolumn report there
are multiple report-dates therefore this strategy would be far too slow.
I'm running out of steam to make pricing behave identically to the old
balance-sheet.

On Wed, 16 Sep 2020 at 16:42, David T. via gnucash-user <
gnucash-u...@gnucash.org> wrote:

> 1. When initially run, I receive an empty report. This is similar to the
> initial result of the basic Transaction report, except in the latter
> case, users are given a note that links them to the report options. It
> would seem to me that at the least, this report should do the same. A
> better solution in both cases would be to have initial parameters that
> return some kind of data--however unrelated to the user's end
> goal--rather than an empty page. It seems to me that users are better at
> changing something they see that is wrong, rather than trying to conjure
> it up out of thin air. (the famous quote from US Supreme Court Justice
> Potter Stewart regarding obscenity comes to mind here: "I know it when I
> see it. This is not it."). In the Balance Sheet, changing the Period
> Duration setting from its default "None" to anything else (I'd suggest
> "Year") yields data from which a user can build. (I have no suggestions
> for the Transaction Report.)
>

This would be worthy of an individual bug report .


> 2. The report defaults to including all accounts, including hidden and
> placeholder accounts. While there is an option on the Accounts tab to
> display hidden accounts, I think the decision to include hidden accounts
> in the report by default is confusing, given that the Account tab
> doesn't display hidden accounts by default. I think it makes more sense
> for the report either to default to omitting hidden accounts, or to
> default to displaying hidden accounts in the options dialog. I see that
> the standard Balance Sheet report also includes hidden accounts by
> default, although this is masked because the standard report limits the
> accounts to 3 levels (the Experimental report defaults to All levels). I
> will note that there is an option on the Display tab to omit zero
> balance accounts, which may have been seen as a way to skip hidden
> accounts. However, while it may not be prudent or common practice to
> hide accounts that have balances, there is nothing in the program to
> prevent this, which means that hiding zero balance accounts is not the
> same as including hidden accounts. I'll note that if I Clear All and
> then click Select All on the Accounts tab, the report properly omits all
> hidden accounts, which it should also do by default. I suggest that both
> reports should default to omitting Hidden accounts on opening, and that
> the default level setting should be the same for both.
>

Also worthy of a bug report. The rationale IMV is that hidden accounts can
carry balances and if they are skipped during report generation, they will
cause undue mismatch between children balances and total parent balances.


>
> 3. The report propagates balances all the way up the account hierarchy,
> which makes sense for accounts denominated in a currency. However, with
> accounts denominated in commodities (such as Stock or Mutual Fund
> accounts), it makes less sense, and in fact renders the report extremely
> difficult to follow, especially with accounts with many different
> commodities. Seeing a full listing of all 150 different commodities (and
> various subsets thereof) repeated for
>
> Assets,
> Assets:Investments,
> Assets:Investments:Taxed,
> Assets:Investments:Taxed:Self, and
> Assets:Investments:Taxable:Self:Brokerage A
>
> gets old and confusing very quickly. It would be better to propagate
> totals for the book currency  only, and leave the tallying of stock and
> mutual fund holdings to the Advanced Portfolio report. I will note that
> initially, I was going to ask why some entries in the report were listed
> as hyperlinks, while others were not. After some puzzling, I figured out
> that the non-linked entries were summarizations of holdings further down
> the hierarchy. Removing the numerous duplications of commodity
> summmarizations would at least make it a little clearer what is going on
> in this regard. I will further note that the standard report does not
> repeat this information up the hierarchy.
>

This multiplication of commodities only takes place if the report does not
convert to target currency. e.g. if you have US tech stocks and set
conversion t

Re: [GNC-dev] "Mortgage Repayment Druid"

[Christopher Lam]

I think it has been renamed to Actions > Scheduled Transactions > Mortgage
& Loan Repayment...? Maybe it has hit a raw nerve with some wizards and
warlords.

On Wed, 16 Sep 2020 at 14:27, Dean Jagels  wrote:

> There are a couple of old enhancement requests that refer to a "Mortgage
> Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?
> The House Mortgate How-To in the doc's makes no mention of such a thing.
>
> Thanks,
> Dean
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Deprecation of XML file

[Christopher Lam]

Just my 2p here. I am a staunch XML user... despite its flaws and too many
namespaces, it has simplicity in viewing/editing with any text editor.

Save/Reload can be done safely with SQLite Rollback mechanism
https://sqlite.org/wal.html -- with this facility I'd expect that datafile
modification (e.g. transaction commits, transaction modification, business
object posting, etc) would be instantaneous, yet Ctrl-S would create a
checkpoint ("Data saved on 2020-09-15 12:06pm") to which I would then be
able to rollback anytime. Rollbacks would be read-only by default, and I'd
want facility to "revert to checkpoint". The atomic change would ideally be
highlightable in UI.

So, I'd not be opposed to migration to SQlite by default, and XML
imports/exports if someone will create an ironclad implementation. SMOP!

On Tue, 15 Sep 2020, 10:04 am Mike Evans,  wrote:

>
> > The *main* benefit of SQL storage is that you get immediate saves.  I.e.,
> > when you commit a transaction, it gets saved to storage immediately.  So
> > -- no lost work.
>
> This is exactly why I *don't* use a database for storage. I often screw up
> entering data.  I don't save until I'm happy I've done it right.  With XML
> I can just reload the file and try again.  With a database I'd have to
> restore the last backup, probably yesterday's, then restart GnuCash and try
> again losing *everything* I did today. (Yes I could manually do a backup of
> the sqlite file after each transaction but...).  With XML I can enter a
> transaction, check that I've not screwed up, save the file, then move on to
> the next transaction, check it and save.  This way If I screw up I can
> simply reload the XML from however many minutes ago I last saved and
> continue.
>
> The no-lost-work maybe fine for some|many but not for me.  The only
> immediate advantage of a DB backend is (as far as I can see) is concurrent
> user access, which GnuCash doesn't do, yet, so until then I will be using
> the XML file storage.  Yes, extracting data with other external programs is
> easier with SQL and If I want to do that I can.  I've never had the need to
> do so though as the reporting features of GnuCash gives me all the data I
> need.
>
>
>
> --
> PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD  3349 982E 6790 44C1 29D0
>
> Use saxic...@protonmail.com for end to end encrypted communication.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Adding a button to abort scrub?

[Christopher Lam]

PR 748 already works well in handling Escape in register scrub, report
building and rendering. The progress bar is augmented by adding state:
inactive, active non cancelable, active & cancelable, active & cancelling.

The idea to add a stop button next to the progress bar is sound, and its
visibility would depend on the cancelable status.

On Thu, 10 Sep 2020, 11:38 pm jean laroche,  wrote:

> > The downside is that it's not terribly discoverable. What can we do to
> make it more so?
>
> I agree, but I don't know how to make the ESC obvious.
>
> > It would be nice to put it in the progress-bar code so that it is
> available by default for all processes that use the progress bar. Check &
> Repair isn't used much but there are plenty of reports that take awhile on
> a large book and it would be nice to be able to stop the report generating
> so one can get to the options dialog and set up the report one really wants.
>
> I thought of that: add an abort button that's handled like the progress
> bar in the code (it's a mess, but it would be easy to duplicate) and can
> be used in all situations where the progress bar is used. I can take a
> look at that. But there might be more pressing things to fix, no?
> Jean
> >> On Sep 9, 2020, at 9:46 AM, Jean Laroche  wrote:
> >>
> >> Wow, that's super nice!
> >> J.
> >>
> >> On 9/9/20 9:43 AM, Christopher Lam wrote:
> >>> See the first commit in https://github.com/Gnucash/gnucash/pull/784
> -- with it you can abort scrub simply by pressing Escape.
> >>> On Thu, 10 Sep 2020, 12:19 am jean laroche,  rip...@gmail.com>> wrote:
> >>> Christopher Lam suggested that the scrubbing process should be
> >>> cancellable via a button (for context, we recently fixed a bug that
> >>> could cause a crash when quitting GC during a scrub operation).
> >>> I took a look at the code and as usual, it's not as easy as I would
> >>> have
> >>> hoped: the backend part (making the scrub stop) is very easy, as
> the
> >>> abort mechanism is already in place. Adding an abort button in the
> >>> right
> >>> place on the relevant windows isn't as easy (see for example how
> the
> >>> progress bar is created/handled, it's fairly convoluted to say the
> >>> least).
> >>> Two questions:
> >>> - Do we really think it's worth the effort given how often
> scrubbing is
> >>> used, and given that scrubbing only takes long on accounts with
> many
> >>> transactions or books with many accounts?
> >>> - If we think it's worth the effort, does one of you devs know how
> to
> >>> easily add the abort button on the main window (and probably the
> >>> account
> >>> transactions window as well)? If so, we could split the task: you
> could
> >>> add the right window, and I'd take it from there.
> >>> Personally I doubt it's worth the effort...
> >>> Jean
> >>> ___
> >>> gnucash-devel mailing list
> >>> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Adding a button to abort scrub?

[Christopher Lam]

See the first commit in https://github.com/Gnucash/gnucash/pull/784 -- with
it you can abort scrub simply by pressing Escape.

On Thu, 10 Sep 2020, 12:19 am jean laroche,  wrote:

> Christopher Lam suggested that the scrubbing process should be
> cancellable via a button (for context, we recently fixed a bug that
> could cause a crash when quitting GC during a scrub operation).
>
> I took a look at the code and as usual, it's not as easy as I would have
> hoped: the backend part (making the scrub stop) is very easy, as the
> abort mechanism is already in place. Adding an abort button in the right
> place on the relevant windows isn't as easy (see for example how the
> progress bar is created/handled, it's fairly convoluted to say the least).
> Two questions:
> - Do we really think it's worth the effort given how often scrubbing is
> used, and given that scrubbing only takes long on accounts with many
> transactions or books with many accounts?
> - If we think it's worth the effort, does one of you devs know how to
> easily add the abort button on the main window (and probably the account
> transactions window as well)? If so, we could split the task: you could
> add the right window, and I'd take it from there.
>
> Personally I doubt it's worth the effort...
>
> Jean
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Introduction

[Christopher Lam]

Welcome, Dean. My goals have been:
- push reports forward to extract as much information as possible from the
rich data available for use
- refactor report infrastructure, homogenise API
- pushing non-report code from guile to C
- improve UI and usability

Bugzilla is a good place to start, but many old bugs are now obsolete. The
mailing list archives and the git history are extremely useful.
Good luck!

On Sun, 6 Sep 2020 at 16:30, John Ralls  wrote:

>
>
> > On Sep 6, 2020, at 9:07 AM, Dean Jagels  wrote:
> >
> > Hello, all.  My name is Dean, and I'm interested in lending a hand.
> I've been doing software design, coding, and requirements definition for
> nearly 40 years.  I now find that I have some time to contribute to an
> open-source project.  I am a Quicken refugee who has been using GnuCash for
> several years now, so I figured I'd give it a go.
> >
> > I see that there are quite a few items in Bugzilla, and some of those
> are quite old.  How do you prioritize them?  Would there be value in me
> picking off some of the old ones to see if they still apply?
>
> Dean,
>
> Welcome!
>
> This being an all-volunteer project, we prioritize largely by individual
> whim. My whim goes something like 1: crashers, 2: breakage likely to affect
> many users, 3: advances my long-term design goals (replacing linked lists
> and hash tables of objects with SQL to replace QofQuery leading to
> multi-user access to the database and ad-hoc reporting, confining Guile use
> to reports, separating view and controller in the GUI code).
>
> Yes, it most certainly would be helpful for you to try to reproduce older
> bugs.
>
> If you haven't already, please review
> https://wiki.gnucash.org/wiki/Development and the pages linked there.
>
> Regards
> John Ralls
>
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] No graphical reports on openSUSE 15.2

[Christopher Lam]

Bugzilla is ok. You don't have to install into your /usr -- I have this in
my cmake line:

-DCMAKE_INSTALL_PREFIX=/home/chris/sources/gnucash/maint-install

On Sun, 6 Sep 2020 at 12:47, Herbert Thoma 
wrote:

> Am 06.09.20 um 13:25 schrieb Christopher Lam:
> > The advice has usually been to run from install dir.
>
> OK, graphical reports work when installing and running from the install
> dir.
>
> After installing the script tag points to a reasonable location:
>  src="file:usr/local/share/gnucash/chartjs/Chart.bundle.min.js">
>
>  > Not sure why build dir cannot show reports anymore.
>
> The GnuCash 3.9 that comes with openSUSE 15.2 uses another script
>  src="file:usr/share/gnucash/jqplot/jquery.min.js">
>
> I am pretty sure that I built 3.9 also myself and that this worked from
> the build dir.
>
> So I think it is likely that graphical reports stopped working from the
> build dir
> when the reports were changed from jqplot to chartjs.
>
> Is this a bug? Should I add this to bugzilla?
>
>
> > On Sun, 6 Sep 2020, 6:33 pm Herbert Thoma, <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>>
> wrote:
> >
> > Am 06.09.20 um 11:32 schrieb Christopher Lam:
> >  > I suspect that ChartJS isn't being loaded at all. Check the html
> for the  tag and whether it's pointing correctly to your
> Chart.bundle.min.js
> >
> > I have:
> > <body bgcolor="#ff"><script language="javascript"
> type="text/javascript" src="file:///">
> >
> >  > Are you running from the build dir instead of the install dir by
> any chance?
> >
> > Yes. I'm running from the build dir. I am pretty sure that graphical
> reports
> > worked from the build dir for GnuCash 3.x. Is this no longer the
> case?
> >
> > There is a borrowed/chartjs/Chart.bundle.min.js file in the source
> dir
> > and a borrowed/chartjs directory in the build dir, but only cmake
> files and
> > a Makefile are in this directory.
> >
> >  > On Sun, 6 Sep 2020 at 08:40, Herbert Thoma <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>
> <mailto:herbert.th...@iis.fraunhofer.de  herbert.th...@iis.fraunhofer.de>>> wrote:
> >  >
> >  > Am 05.09.20 um 19:13 schrieb Christopher Lam:
> >  >  > Not sure why this would fail. Edit html-chart.scm and
> delete the relevant (push "Chart"...) line. My setup successfully sets the
> Chart option. If this fails then I'm not sure, you'll have to dig in.
> >  >
> >  > If I comment out the line, then I get the
> >  > ReferenceError: Can't find variable: Chart
> >  > somewhere else:
> >  >
> >  > // draw the background color
> >  > Chart.pluginService.register({
> >  > beforeDraw: function (chart, easing) {
> >  >
> >  > I really would like to debug this, but I have no clue about
> >  > java script. So any hints on where to start are very welcome.
> >  >
> >  >  >
> >  >  > On Sat, 5 Sep 2020 at 16:47, Herbert Thoma <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>
> <mailto:herbert.th...@iis.fraunhofer.de  herbert.th...@iis.fraunhofer.de>> <mailto:herbert.th...@iis.fraunhofer.de
> <mailto:herbert.th...@iis.fraunhofer.de>  herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>>>>
> wrote:
> >  >  >
> >  >  > Am 05.09.20 um 17:28 schrieb Christopher Lam:
> >  >  >  > What happens with combined reports eg net worth
> line chart with display/table enabled?
> >  >  >
> >  >  > I see the table, no chart.
> >  >  >
> >  >  >  > Try right click the blank page and open the WebKit
> inspector, and report the console messages. Maybe chartjs is not being
> found.
> >  >  >
> >  >  > I get 2 errors:
> >  >  >
> >  >  > SystaxError: Unexpected token '<'
> >  >  >(anonymous function) --- file:///:1
> >  >  >
> >  >  > This one I think is a bit strange, because it points
> to the first line in the report html code.
> >  >  >
> 

Re: [GNC-dev] No graphical reports on openSUSE 15.2

[Christopher Lam]

The advice has usually been to run from install dir. Not sure why build dir
cannot show reports anymore.

On Sun, 6 Sep 2020, 6:33 pm Herbert Thoma, 
wrote:

> Am 06.09.20 um 11:32 schrieb Christopher Lam:
> > I suspect that ChartJS isn't being loaded at all. Check the html for the
>  tag and whether it's pointing correctly to your Chart.bundle.min.js
>
> I have:
> <body bgcolor="#ff"><script language="javascript"
> type="text/javascript" src="file:///">
>
> > Are you running from the build dir instead of the install dir by any
> chance?
>
> Yes. I'm running from the build dir. I am pretty sure that graphical
> reports
> worked from the build dir for GnuCash 3.x. Is this no longer the case?
>
> There is a borrowed/chartjs/Chart.bundle.min.js file in the source dir
> and a borrowed/chartjs directory in the build dir, but only cmake files and
> a Makefile are in this directory.
>
> > On Sun, 6 Sep 2020 at 08:40, Herbert Thoma <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>>
> wrote:
> >
> > Am 05.09.20 um 19:13 schrieb Christopher Lam:
> >  > Not sure why this would fail. Edit html-chart.scm and delete the
> relevant (push "Chart"...) line. My setup successfully sets the Chart
> option. If this fails then I'm not sure, you'll have to dig in.
> >
> > If I comment out the line, then I get the
> > ReferenceError: Can't find variable: Chart
> > somewhere else:
> >
> > // draw the background color
> > Chart.pluginService.register({
> > beforeDraw: function (chart, easing) {
> >
> > I really would like to debug this, but I have no clue about
> > java script. So any hints on where to start are very welcome.
> >
> >  >
> >  > On Sat, 5 Sep 2020 at 16:47, Herbert Thoma <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>
> <mailto:herbert.th...@iis.fraunhofer.de  herbert.th...@iis.fraunhofer.de>>> wrote:
> >  >
> >  > Am 05.09.20 um 17:28 schrieb Christopher Lam:
> >  >  > What happens with combined reports eg net worth line chart
> with display/table enabled?
> >  >
> >  > I see the table, no chart.
> >  >
> >  >  > Try right click the blank page and open the WebKit
> inspector, and report the console messages. Maybe chartjs is not being
> found.
> >  >
> >  > I get 2 errors:
> >  >
> >  > SystaxError: Unexpected token '<'
> >  >(anonymous function) --- file:///:1
> >  >
> >  > This one I think is a bit strange, because it points to the
> first line in the report html code.
> >  >
> >  >
> >  > ReferenceError: Can't find variable: Chart
> >  >Global Code --- gnc-report-7J8DQ0.html:185
> >  >
> >  > here the line in the code is:
> >  > Chart.defaults.global.defaultFontFamily = "'Trebuchet MS',
> Arial, Helvetica, sans-serif";
> >  >
> >  >
> >  >Herbert.
> >  >
> >  >  > On Sat, 5 Sep 2020, 10:41 pm Herbert Thoma, <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>
> <mailto:herbert.th...@iis.fraunhofer.de  herbert.th...@iis.fraunhofer.de>> <mailto:herbert.th...@iis.fraunhofer.de
> <mailto:herbert.th...@iis.fraunhofer.de>  herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>>>>
> wrote:
> >  >  >
> >  >  > Hi!
> >  >  >
> >  >  > I built GnuCash on openSUSE 15.2. from git. Everything
> works as expected,
> >  >  > with one exception: graphical reports are not
> displayed. Text reports work.
> >  >  >
> >  >  > I exported a report as html and tested in firefox.
> This displays an empty
> >  >  > page, too.
> >  >  >
> >  >  > openSUSE 15.2 comes with a packaged GnuCash 3.9, there
> the graphical
> >  >  > reports work.
> >  >  >
> >  >  > Any ideas why the reports don't work?
> >  >  > Any hints how I could debug this?
> >  >  >
> >  >  >Herbert.
> > 

Re: [GNC-dev] No graphical reports on openSUSE 15.2

[Christopher Lam]

I suspect that ChartJS isn't being loaded at all. Check the html for the

Re: [GNC-dev] No graphical reports on openSUSE 15.2

[Christopher Lam]

Not sure why this would fail. Edit html-chart.scm and delete the relevant
(push "Chart"...) line. My setup successfully sets the Chart option. If
this fails then I'm not sure, you'll have to dig in.

On Sat, 5 Sep 2020 at 16:47, Herbert Thoma 
wrote:

> Am 05.09.20 um 17:28 schrieb Christopher Lam:
> > What happens with combined reports eg net worth line chart with
> display/table enabled?
>
> I see the table, no chart.
>
> > Try right click the blank page and open the WebKit inspector, and report
> the console messages. Maybe chartjs is not being found.
>
> I get 2 errors:
>
> SystaxError: Unexpected token '<'
>   (anonymous function) --- file:///:1
>
> This one I think is a bit strange, because it points to the first line in
> the report html code.
>
>
> ReferenceError: Can't find variable: Chart
>   Global Code --- gnc-report-7J8DQ0.html:185
>
> here the line in the code is:
> Chart.defaults.global.defaultFontFamily = "'Trebuchet MS', Arial,
> Helvetica, sans-serif";
>
>
>   Herbert.
>
> > On Sat, 5 Sep 2020, 10:41 pm Herbert Thoma, <
> herbert.th...@iis.fraunhofer.de <mailto:herbert.th...@iis.fraunhofer.de>>
> wrote:
> >
> > Hi!
> >
> > I built GnuCash on openSUSE 15.2. from git. Everything works as
> expected,
> > with one exception: graphical reports are not displayed. Text
> reports work.
> >
> > I exported a report as html and tested in firefox. This displays an
> empty
> > page, too.
> >
> > openSUSE 15.2 comes with a packaged GnuCash 3.9, there the graphical
> > reports work.
> >
> > Any ideas why the reports don't work?
> > Any hints how I could debug this?
> >
> >Herbert.
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] No graphical reports on openSUSE 15.2

[Christopher Lam]

What happens with combined reports eg net worth line chart with
display/table enabled?

Try right click the blank page and open the WebKit inspector, and report
the console messages. Maybe chartjs is not being found.

On Sat, 5 Sep 2020, 10:41 pm Herbert Thoma, 
wrote:

> Hi!
>
> I built GnuCash on openSUSE 15.2. from git. Everything works as expected,
> with one exception: graphical reports are not displayed. Text reports work.
>
> I exported a report as html and tested in firefox. This displays an empty
> page, too.
>
> openSUSE 15.2 comes with a packaged GnuCash 3.9, there the graphical
> reports work.
>
> Any ideas why the reports don't work?
> Any hints how I could debug this?
>
>   Herbert.
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Christopher Lam]

Unfortunately cleaning up advanced-portfolio.scm is much more challenging
than I expected, so, I've now reverted it to its original (as of 4.0)
state, with suitable changes to support guile-3.0 only.

On Sat, 1 Aug 2020 at 05:55, Christopher Lam  wrote:

> Updated  via  https://github.com/Gnucash/gnucash/commit/12ab85fa (commit)
>  via  https://github.com/Gnucash/gnucash/commit/6f196031 (commit)
> from  https://github.com/Gnucash/gnucash/commit/4df6493b (commit)
>
>
>
> commit 12ab85fa6c147df2714a14c778412f930f89ed40
> Author: Christopher Lam 
> Date:   Sat Aug 1 10:12:38 2020 +0800
>
> [advanced-portfolio] use G_ for guile-3.0
>
> diff --git a/gnucash/report/reports/standard/advanced-portfolio.scm
> b/gnucash/report/reports/standard/advanced-portfolio.scm
> index 279fcb91f..192e97e63 100644
> --- a/gnucash/report/reports/standard/advanced-portfolio.scm
> +++ b/gnucash/report/reports/standard/advanced-portfolio.scm
> @@ -1048,8 +1048,8 @@ by preventing negative stock balances.")
> (lambda (foreign domestic date)
>  (find-price
> (gnc-pricedb-lookup-nearest-in-time-any-currency-t64
>  pricedb foreign (time64CanonicalDayTime date))
> domestic)
> -  (headercols (list (_ "Account")))
> -  (totalscols (list (gnc:make-html-table-cell/markup
> "total-label-cell" (_ "Total"
> +  (headercols (list (G_ "Account")))
> +  (totalscols (list (gnc:make-html-table-cell/markup
> "total-label-cell" (G_ "Total"
>(sum-total-moneyin (gnc-numeric-zero))
>(sum-total-income (gnc-numeric-zero))
>(sum-total-both-gains (gnc-numeric-zero))
> @@ -1060,37 +1060,37 @@ by preventing negative stock balances.")
>
>   ;;begin building lists for which columns to display
>(if show-symbol
> - (begin (append! headercols (list (_ "Symbol")))
> + (begin (append! headercols (list (G_ "Symbol")))
>  (append! totalscols (list " "
>
>   (if show-listing
> - (begin (append! headercols (list (_ "Listing")))
> + (begin (append! headercols (list (G_ "Listing")))
>  (append! totalscols (list " "
>
>   (if show-shares
> - (begin (append! headercols (list (_ "Shares")))
> + (begin (append! headercols (list (G_ "Shares")))
>  (append! totalscols (list " "
>
>   (if show-price
> - (begin (append! headercols (list (_ "Price")))
> + (begin (append! headercols (list (G_ "Price")))
>  (append! totalscols (list " "
>
>   (append! headercols (list " "
> -   (_ "Basis")
> -   (_ "Value")
> -   (_ "Money In")
> -   (_ "Money Out")
> -   (_ "Realized Gain")
> -   (_ "Unrealized Gain")
> -   (_ "Total Gain")
> -   (_ "Rate of Gain")
> -   (_ "Income")))
> +   (G_ "Basis")
> +   (G_ "Value")
> +   (G_ "Money In")
> +   (G_ "Money Out")
> +   (G_ "Realized Gain")
> +   (G_ "Unrealized Gain")
> +   (G_ "Total Gain")
> +   (G_ "Rate of Gain")
> +   (G_ "Income")))
>
>   (if (not (eq? handle-brokerage-fees 'ignore-brokerage))
> - (append! headercols (list (_ "Brokerage Fees"
> + (append! headercols (list (G_ "Brokerage Fees"
>
> - (append! headercols (list (_ "Total Return")
> -   (_ "Rate of Return")))
> + (append! headercols (list (G_ "Total Return")
> +   (G_ "Rate of Return")))
>
>(append! totalscols (list " "))
>
> @@ -1187,14 +1187,14 @@ b

Re: [GNC-dev] Dev's features of choice?

[Christopher Lam]

LUndo/redo could be implemented as a journalling type table, where each new
row describes the change in state. But then you're recreating sqlite, and
would require deep architectural changes. Probably not possible in this
lifetime.

On Mon, 27 Jul 2020, 12:33 pm jean laroche,  wrote:

> OK thanks for all the opinions. As usual with collaborative projects,
> it's a bit messy, we don't all have the very same optics, which I think
> is probably a good thing!
>
> I would agree with John that undo/redo is very challenging if it's
> applicable to all actions with "infinite" undo/redo. I've thought about
> it a bit, and there's nothing that seems easy to me that would give a
> fully functional undo/redo. Even if you saved the state of the database
> for every action (granularity to be defined!) restoring it, and going
> back exactly where you were would not be a simple matter...
>
> In any case, thanks for chiming in.
> Jean
>
>
> On 7/26/2020 8:52 PM, John Ralls wrote:
> > There's already a cancel button for the first part.
> >
> > There's no undelete, but it wouldn't be to hard to implement: Just make
> a second set of QofContainers to hold deleted objects until the end of the
> session and provide a dialog to list them and allow them to be returned to
> the primary container.
> >
> > The normal undo-redo stacks common in other programs would be a bit more
> complex but the technique is well known, it's just really tedious to
> implement. Where the problem gets quite a bit more interesting (read:
> complex and difficult with decisions about depth and granularity) is when
> the undo stack reaches back into already committed transactions. Do you
> save a copies of each object for every keystroke or treat an edited
> transaction like a deleted one? How do you handle an import of many
> transactions, some new and some matched-and-updated? That's just the
> beginning, GnuCash is complicated. It could easily turn into several years
> work for a skilled software engineer; definitely not a job for a hacker.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> >>
> >> While I'm not a professional, there is a point about undo that I would
> like to see - sooner than later:  I start to edit a transaction but, before
> I commit it (press enter or move to another transaction). I realize that I
> didn't want to do that and would like to cancel my edit, restoring the
> transaction to what it was.
> >>
> >> And, I have accidentally deleted a transaction on more than one
> occasion.  It would be great if I could restore that transaction rather
> than completely re-enter it, hoping I remembered what was in it - I don't!
> >> Bruce
> >> Preach the Gospel wherever you go.
> >> If necessary, use words.
> >>
> >> Hi Jean,
> >>
> >> Am 26.07.20 um 19:57 schrieb jean laroche:
> >>> I'm curious about something:
> >>> If you're a GC dev, contributing code to the project, what's the
> >>> feature(s) you'd like to see added to GC?
> >>> I'm only contributing a bit, but I'll offer my 3 top wishes:
> >>> - Undo/(redo)
> >>> - Multi-transaction (bulk) editing
> >>> - Multi-account (bulk) editing
> >> All three are violations of strict accounting rules. We often talk about
> >> "In the times of ink and paper", not graphite (pencils). Some
> >> governments require the immutabiity of once written records.
> >>
> >> So I see at least a better auditing system as a requirement before your
> >> suggestions. The current logging would need a review. It should cover
> >> all changes, not only simple transactions. ISTR business actions and
> >> structural changes are not recorded.
> >>
> >>> I'm curious specifically about devs because they typically have a
> >>> different perspective on the project than users have.
> >>> Jean
> >> About the future I almost agree with Johns suggestions.
> >>
> >> Regards
> >> Frank
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dev's features of choice?

[Christopher Lam]

Jean as usual the best answer is to push the code forward in ways that you
are best capable and willing to do. If they require deep architectural
changes that are impossible to maintain, or simply badly written code, then
they will be rejected. But if you feel they will be well received then
go for it. I still think your proposals are positive contributions.

On Mon, 27 Jul 2020, 1:58 am jean laroche,  wrote:

> I'm curious about something:
> If you're a GC dev, contributing code to the project, what's the
> feature(s) you'd like to see added to GC?
> I'm only contributing a bit, but I'll offer my 3 top wishes:
> - Undo/(redo)
> - Multi-transaction (bulk) editing
> - Multi-account (bulk) editing
>
> I'm curious specifically about devs because they typically have a
> different perspective on the project than users have.
> Jean
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Building GnuCash 4.0 on Linux MInt20

[Christopher Lam]

Guile 3 is now supported, so do try again on latest maint!

On Sat, 11 Jul 2020, 9:28 am David Cousens, 
wrote:

> Thnaks Christopher,
> I'll down grade it and see how it goes. I started off initially with the
> default libraries loaded in LM20 using apt. I noticed a few of the default
> libraries are well  in advanece of the current gnucash requirements. e.g.
>  libboost 1.71.
> David
>
> On Sat, 2020-07-11 at 01:04 +, Christopher Lam wrote:
>
> You have guile-3.0 which has backward incompatible changes, and not yet
> supported. Try guile-2.2.
>
> On Sat, 11 Jul 2020 at 00:20, David Cousens 
> wrote:
>
> Having a problem building on a new install of Linux Mint Ulyana (20).
>
> Can anyone make sense of the following? It appears to be a problem with
> gettext. I have 0.19.8.1-10build1 installed but
> noted in the cmake initial output when I was installing the dependencies
> that 2.0 was preferred but only required for
> building a translation file. I assumed this to mean 0.19.8 would be OK for
> the app.
>
> Cmake output:
> $ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DWITH_PYTHON=ON ..
> CMake Warning at CMakeLists.txt:251 (message):
>   Gettext version 0.20 or more recent is required to translate the
>   'developer_name' tag in gnucash.appdata.xml.  All but that tag will be
>   translated in the generated file.
>
>
> -- Using guile-2.0.x
> -- Using guile SRFI-64
> -- Using guile textual-ports
> -- Checking for GTEST
> -- Checking for GMOCK
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /home/david/Applications/gnucash-4.0/build
>
> ninja output:
> $ ninja
> [6/243] Generating
> ../../lib/x86_64-li...cache/gnucash/app-utils/c-interface.go
> FAILED:
> lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/app-utils/c-interface.go
> cd /home/david/Applications/gnucash-4.0/build/libgnucash/app-utils &&
> /usr/bin/cmake -E env
>
> LD_LIBRARY_PATH=/home/david/Applications/gnucash-4.0/build/lib:/home/david/Applications/gnucash-4.0/build/lib/gnucash:
> GNC_UNINSTALLED=YES GNC_BUILDDIR=/home/david/Applications/gnucash-4.0/build
>
> GUILE_LOAD_PATH=/home/david/Applications/gnucash-4.0/libgnucash/app-utils:/home/david/Applications/gnucash-
>
> 4.0/build/libgnucash/app-utils:/home/david/Applications/gnucash-4.0/build/libgnucash/app-
>
> utils/deprecated:/home/david/Applications/gnucash-4.0/build/share/guile/site/3.0
>
> GUILE_LOAD_COMPILED_PATH=/home/david/Applications/gnucash-4.0/build/libgnucash/app-
>
> utils:/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
>
> ccache:/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated
>
> GNC_MODULE_PATH=/home/david/Applications/gnucash-4.0/build/lib:/home/david/Applications/gnucash-4.0/build/lib/gnucash:
> /usr/bin/guile -e "(@@ (guild) main)" -s /usr/bin/guild compile -o
> /home/david/Applications/gnucash-
> 4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/app-utils/c-interface.go
> /home/david/Applications/gnucash-
> 4.0/libgnucash/app-utils/c-interface.scm
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Syntax error:
> c-interface.scm:83:21: _: bad use of '_' syntactic keyword in subform (_
> (hash-ref string-hash key)) of (_ (hash-ref
> string-hash key))
> [7/243] Generating
> ../../lib/x86_64-li...ucash/deprecated/migrate-prefs-user.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated/migrate-
> prefs-user.go'
> [8/243] Generating
> ../../lib/x86_64-li...he/gnucash/deprecated/migrate-prefs.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated/migrate-
> prefs.go'
> [12/243] Generating
> ../../lib/x86_64-l...deprecated/gnucash/unittest-support.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
> ccache/gnucash/deprecated/gnucash/unittest-support.go'
> [13/243] Generating
> ../../lib/x86_64-l.../gnucash/deprecated/gnucash/gettext.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
> ccache/gnucash/deprecated/gnucash/gettext.go'
> ninja: build stopped: subcommand failed.
>
> cmake error log attached
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> --
>
> Dr David R Cousens
> B.Sc, M.Prof. Acc., Ph.D., G.C.Ed
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Building GnuCash 4.0 on Linux MInt20

[Christopher Lam]

You have guile-3.0 which has backward incompatible changes, and not yet
supported. Try guile-2.2.

On Sat, 11 Jul 2020 at 00:20, David Cousens 
wrote:

> Having a problem building on a new install of Linux Mint Ulyana (20).
>
> Can anyone make sense of the following? It appears to be a problem with
> gettext. I have 0.19.8.1-10build1 installed but
> noted in the cmake initial output when I was installing the dependencies
> that 2.0 was preferred but only required for
> building a translation file. I assumed this to mean 0.19.8 would be OK for
> the app.
>
> Cmake output:
> $ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DWITH_PYTHON=ON ..
> CMake Warning at CMakeLists.txt:251 (message):
>   Gettext version 0.20 or more recent is required to translate the
>   'developer_name' tag in gnucash.appdata.xml.  All but that tag will be
>   translated in the generated file.
>
>
> -- Using guile-2.0.x
> -- Using guile SRFI-64
> -- Using guile textual-ports
> -- Checking for GTEST
> -- Checking for GMOCK
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /home/david/Applications/gnucash-4.0/build
>
> ninja output:
> $ ninja
> [6/243] Generating
> ../../lib/x86_64-li...cache/gnucash/app-utils/c-interface.go
> FAILED:
> lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/app-utils/c-interface.go
> cd /home/david/Applications/gnucash-4.0/build/libgnucash/app-utils &&
> /usr/bin/cmake -E env
>
> LD_LIBRARY_PATH=/home/david/Applications/gnucash-4.0/build/lib:/home/david/Applications/gnucash-4.0/build/lib/gnucash:
> GNC_UNINSTALLED=YES GNC_BUILDDIR=/home/david/Applications/gnucash-4.0/build
>
> GUILE_LOAD_PATH=/home/david/Applications/gnucash-4.0/libgnucash/app-utils:/home/david/Applications/gnucash-
>
> 4.0/build/libgnucash/app-utils:/home/david/Applications/gnucash-4.0/build/libgnucash/app-
>
> utils/deprecated:/home/david/Applications/gnucash-4.0/build/share/guile/site/3.0
>
> GUILE_LOAD_COMPILED_PATH=/home/david/Applications/gnucash-4.0/build/libgnucash/app-
>
> utils:/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
>
> ccache:/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated
>
> GNC_MODULE_PATH=/home/david/Applications/gnucash-4.0/build/lib:/home/david/Applications/gnucash-4.0/build/lib/gnucash:
> /usr/bin/guile -e "(@@ (guild) main)" -s /usr/bin/guild compile -o
> /home/david/Applications/gnucash-
> 4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/app-utils/c-interface.go
> /home/david/Applications/gnucash-
> 4.0/libgnucash/app-utils/c-interface.scm
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Syntax error:
> c-interface.scm:83:21: _: bad use of '_' syntactic keyword in subform (_
> (hash-ref string-hash key)) of (_ (hash-ref
> string-hash key))
> [7/243] Generating
> ../../lib/x86_64-li...ucash/deprecated/migrate-prefs-user.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated/migrate-
> prefs-user.go'
> [8/243] Generating
> ../../lib/x86_64-li...he/gnucash/deprecated/migrate-prefs.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/deprecated/migrate-
> prefs.go'
> [12/243] Generating
> ../../lib/x86_64-l...deprecated/gnucash/unittest-support.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
> ccache/gnucash/deprecated/gnucash/unittest-support.go'
> [13/243] Generating
> ../../lib/x86_64-l.../gnucash/deprecated/gnucash/gettext.go
> wrote
> `/home/david/Applications/gnucash-4.0/build/lib/x86_64-linux-gnu/guile/3.0/site-
> ccache/gnucash/deprecated/gnucash/gettext.go'
> ninja: build stopped: subcommand failed.
>
> cmake error log attached
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] 4.0 and C++?

[Christopher Lam]

IIUC this is a desired trend, waiting for good pair of hands!

On Thu, 9 Jul 2020, 12:33 am Jean Laroche,  wrote:

> Maybe I mis-remember, but I thought that 4.0 would be the version where
> we switch from using C to using C++ + boost etc for most of the code in
> GC...
> Was I confused? Is there still a plan to do this rewrite? If so how far
> along is it, and when will it be folded into the current branches?
>
> J.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 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: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
>> > positive numbers and the other with negative numbers.
>> >
>>
>> It is. What's not reasonable is to have a preference (as opposed to a
>> book option) that changes which is negative, especially for stored values.
>> Even having a book option is dicey unless that option affects exactly one
>> place in all of GnuCash's code base.
>>
>> Regards,
>> John Ralls
>>
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Patelco stopped supporting OFX... other options

[Christopher Lam]

Are you saying that SISS isn't compliant with OAIC's APP? Very interesting,
and not surprising...
I've noticed lots of discrepancies in Australian law and practice.
e.g. many forms in use have PDF forms with PDF's signatures, but the
recipient expect nothing other than print+sign+scan+unencrypted email
PDF/JPG.

On Sun, 21 Jun 2020 at 05:28, Liz Dodd  wrote:

> On Sat, 20 Jun 2020 13:43:13 -0700
> jean laroche  wrote:
>
> > > I found an explanation of Quicken's Express Web Connect at
> > >
> https://community.quicken.com/discussion/7851859/faq-how-quicken-connects-with-your-financial-institution-tips-tricks-and-best-practices
> .
> > >
> > > The short answer is it works the same as plaid and friends: The
> > > transaction data is retrieved nightly and stored on Intuit's
> > > servers and Quicken phones home to retrieve them.
> > >
> > > Regards,
> > > John Ralls
> > >
> > That's interesting! They even mention screen scraping (I'm not sure
> > whether that's really what's happening, I would imagine that would be
> > extremely unreliable). I'm sure most data aggregators (such as plaid)
> > no longer use screen scraping, they must have agreements with Banks
> > to download directly, but I'm not too sure about this.
>
> I've found all of this very interesting. It doesn't meet my idea of
> secure. My idea is I hold my keys, and never share them.
> Various instructions from my bank include not sharing PINs so why would
> I want to share anything else that gave access (even read only)?
>
> I followed through to an Australian broker for these services and have
> their assurance that everything is safe and encrypted.
> It is quite clear on the website that the data gets sent daily, but
> there is not any clarity if it is stored on the route.
>
> https://quickbooks.intuit.com/au/resources/product-updates/save-time-direct-bank-feeds/
> The advertised broker has an email address on that page with a parked
> domain. This is their correct domain https://sissdataservices.com.au/
>
> from where I get this jargon filled piece
> 
>
> Our consent driven open banking REST API enables accounting software,
> FinTechs, RegTechs and innovators to quickly and securely connect to
> consumer data from Australia's major banks and financial institutions.
>
> Access accurate (reconciled daily) and reliable (direct from core
> banking systems) open banking data via a single REST API.
>
> SISS Data Services has entered into formal data supply contracts with
> Australia’s largest banks and financial institutions to provide you
> access to consumer data.
>
> Modelled on the Consumer Data Right (CDR) framework, SISS Data Services
> provides you with all the resources you need to build and grow your
> solution, including REST API, accreditation, and developer sandbox.
> Search our data feeds How our data feeds work Click to enlarge
> Key features
> DIRECT DATA FEEDS
>
> High quality data feeds directly from the banks
>
> SANDBOX + DEVELOPMENT
>
> Start building your API today in our sandbox
>
> MORE DATA
>
> Look at the growing list of banks we have partnered with to date
>
> DATA RECIPIENT ACCREDITATION
>
> One central location to complete all your compliance
>
> SINGLE REST API FOR BANK DATA
>
> Single REST API to connect to bank data
>
> Who is the open banking REST API designed for?
>
> The open banking REST API is designed for accounting software providers
> (ASP), FinTechs, RegTechs and software developers wanting access to
> accurate and reliable balance and transaction information for credit
> cards and bank accounts.
>
> ✓ Single REST API
> ✓ Sandbox & Development Portal
> ✓ Transactional Based Pricing
> ✓ Major Banks
> ✓ Accurate & Reliable Data
> ✓ Direct Data Feeds (Core Banking System)
>
> We keep costs simple
>
> Our transactional pricing is month-to-month with no lock-in contract
> and no exit penalties. It is designed to get you connected quickly.
>
> Set up fee: Access to our incredible support team and the developer
> sandbox to connect your app.
>
> SISS fee: A per transaction fee for our product and service.
>
> Bank fee: This is the exact fee the banks charge us, directly passed
> onto you with zero mark ups.
>
> Set up fee $5,000 +GST
> SISS fee $0.03 (3 cents) +GST per line item
> Bank fee Nil to $0.05 (5 cents) +GST per line item
> ==
>
> Now we've got a cost sample as well.
> I am not seeing a way for an individual to do this directly with the
> bank, and being able to cut out the middleman whether for security or
> cost reasons.
>
> But if your financial institution chose to use one of these services
> and cut out customer driven direct download services, they are up
> against consumer law in several jurisdictions. It's known as third
> party forcing here, and isn't approved.
>
> Liz
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-

Re: [GNC-dev] [GNC] GnuCash 3.905 Released

[Christopher Lam]

A couple of notes:
- Balance-sheet is reverted back to the legacy report: multicolumn
balance-sheet had a few more bugs identified related to currency
conversions, so, isn't ready yet. The latter is downgraded back to
experimental submenu.
- gnucash-cli --report run --name "VAT Report" --export-type CSV
--output-file VAT.CSV, when "Income and GST Statement" is properly set up
and saved as "VAT Report", would be a convenient way to generate the VAT
figures and save as CSV. Also applicable for Australian BAS reports.

On Sun, 14 Jun 2020 at 23:21, John Ralls  wrote:

> The GnuCash development team announces GnuCash 3.905, the fourth testing
> release for what will soon be GnuCash 4.0.
>
> Changes
>
> Baseline requirements
>
> Operating Systems:
>
> • Linux: Ubuntu 18.04LTS
> • MacOS: 10.13
> • Windows: 8.1
> Software Dependencies:
>
> • C++ standard is now C++17, requires gcc 8.0 or clang 6.0.
> • Cmake 3.10
> • boost 1.67.0
> • gettext 0.19.6 for general use, 0.20 to generate gnucash.pot.
> • glib-2.0 2.56.1, gtk 3.22.30
> • googletest 1.8.0
> • ICU, any version.
> • libdbi 0.8.3
> • libxml2 2.9.4
> • swig 3.0.12 Now required for building from tarballs as well as
> from git.
> • Webkit 2.4.11 Mac & Win32, 2.14.1 Linux/BSD
> New Features
>
> The intent is to have command categories with subcommands to better enable
> a richer command line capability as illustrated with the new report
> commands list and show.
>
> • A new separate executable, gnucash-cli (gnucash-cli.exe on
> Microsoft Windows) for doing command-line things like updating the prices
> in your book. gnucash-cli gains the ability to run reports from the command
> line. Specify reports to run by name or guid. It also provides an export
> format and an output file name without which it will output the report to
> stdout.
> • gnucash-cli --report run --name=[reportname/guid]
> datafile.gnucash
> • gnucash-cli --report run --name=[reportname/guid]
> --output-file=x.html datafile.gnucash
> • gnucash-cli --report run --name=[reportname/guid]
> --output-file=x.html --export-type=TYPE datafile.gnucash
> The GUI command, gnucash responds to the same command line arguments. In
> order to provide more options its syntax (and gnucash-cli's) for quote
> retrieval is changed from --add-quotes to --quotes get.
>
> • When deleting accounts the destination accounts of moved splits
> will be checked to ensure that they have the same commodity as the source
> account. If they don't you'll get a warning and the opportunity to pick
> another account or to carry on regardless.
> • New type-ahead search added to sequential search when selecting
> an account in the register: Instead of typing the first few characters of a
> top level account, the separator, the first few characters of the next
> level account and so on you may instead type a few characters of any part
> of a full account name and the drop-list will be filtered to contain only
> matching accounts. Once you have a small enough list you can use the arrow
> keys to select the account that you want.
> • Python bindings are now localized and their strings available
> for translation.
> • The new reports introduced in the Experimental Reports menu are
> moved to the main menu and the old reports hidden; the old reports can be
> unhidden by running GnuCash from the commandline with the --extra argument.
> That will cause the old reports to appear in their regular locations on the
> menu labeled (legacy). Note that new reports use different options and
> layouts and you may need to adjust your saved report configurations.
> • A new Transaction Association dialog, available from the new
> Update Transaction Association item in the register context menu, provides
> the ability to have multiple associations for a single transaction.
> Associations may now be easily removed.
> • Allow Associations to be added to invoices. The actual
> association when present is added as a link button which is shown below the
> notes.
> • A symbol is now displayed on transactions in the register when
> they have an attachment and the selected font supports the symbol.
> • The OFX file importer can now import more than one file at a
> time.
> • A new report menu supbmenu Multicolumn contains the old
> custom-multicolumn report and a new Dashboard report containing Account
> reports for expenses and income, an income-expense chart, and an account
> summary.
> • When importing, the matcher will no longer offer to match a
> transaction to one that has already matched in a previous import, nor will
> it offer to match more than one imported transaction to a single existing
> transaction.
> • Support for UK VAT and Australian GST added to the Income-GST
> report. The reports options are

Re: [GNC-dev] Feedback on GnuCash 3.903

[Christopher Lam]

The balance sheet date option does not transfer because old balance sheet
uses "Balance Sheet Date" whereas upgraded one uses "End Date". I am not
sure it is practical to set up a compatibility pathway -- new balance sheet
can report multiple dates.

On Fri, 5 Jun 2020, 7:27 am mark sattolo,  wrote:

> Yes, that makes sense. I did some more digging around, and not all my
> custom column widths were changed, just those for any of the accounts that
> I actually opened while using version 3.903. Which happened to be quite a
> few as I was testing various transactions, etc.
>
>
> *Mark Sattolo*
> *mh.sa...@gmail.com *
>
>
>
> On Thu, Jun 4, 2020 at 7:15 PM D.  wrote:
>
> > Mark,
> >
> > If that's true, I imagine it's a mistake. At least I hope so! I trust the
> > devs will fix it, since I'd be pretty upset to have to reset column
> widths
> > on all my accounts...
> >
> > David
> >
> >
> >  Original Message 
> > From: mark sattolo 
> > Sent: Thu Jun 04 19:07:27 EDT 2020
> > To: gnucash-devel 
> > Subject: Re: [GNC-dev] Feedback on GnuCash 3.903
> >
> > Also fyi, I just noticed that version 3.903 overwrote all the custom
> column
> > width settings in my gcm file and changed all of them to a new default
> set
> > of widths, I presume the new defaults for Gnucash 4. These new default
> > widths give a very wide *description* column and every other column is
> very
> > narrow and especially for the *date*, *num* and *transfer* columns, too
> > narrow to fit the text they contain. Again, I had to restore my backup
> gcm
> > file to restore all my custom settings.
> >
> > So I guess since this will eventually be released as Gnucash version
> 4.xxx,
> > we are to expect breaking changes from the current version? And users
> will
> > be warned that they will be losing custom settings for column widths,
> saved
> > reports, etc when they switch over?
> >
> >
> > cheers,
> >
> > *Mark Sattolo*
> > *mh.sa...@gmail.com *
> >
> >
> >
> > On Thu, Jun 4, 2020 at 11:45 AM Christopher Lam <
> christopher@gmail.com
> > >
> > wrote:
> >
> > > Good luck. I've just verified that the old (3.x) balance-sheet date
> > > defaults to "end-of-accounting-period", so, the first few lines
> shouldn't
> > > be added.
> > >
> > > On Thu, 4 Jun 2020 at 15:41, mark sattolo  wrote:
> > >
> > >>
> > >> Thanks. I'll give it a try. I'll just update the source in my git
> folder
> > >> for tag 3.903 and rebuild if I can't figure out how to modify the
> > flatpak.
> > >>
> > >> *Mark Sattolo*
> > >> *mh.sa...@gmail.com *
> > >> *(613) 447-5385*
> > >>
> > >>
> > >> On Thu, Jun 4, 2020 at 11:36 AM Christopher Lam <
> > >> christopher@gmail.com> wrote:
> > >>
> > >>> Hi Mark
> > >>>
> > >>> The reports for balance-sheet and income-statement were replaced with
> > >>> the multicolumn ones. See the release notes. This was described in
> > devel a
> > >>> few weeks/months ago.
> > >>>
> > >>> Try the following patch which will reduce the discrepancy in the
> > default
> > >>> options between old and new. You may be able to modify the patch from
> > >>> within the flatpak (but I'm not sure).
> > >>>
> > >>> modified   gnucash/report/reports/standard/balsheet-pnl.scm
> > >>> @@ -176,6 +176,9 @@ also show overall period profit & loss."))
> > >>>  (gnc:options-add-date-interval!
> > >>>   options gnc:pagename-general optname-startdate optname-enddate
> > "c")
> > >>>
> > >>> +(gnc:option-set-default-value
> > >>> + (gnc:lookup-option options gnc:pagename-general
> optname-enddate)
> > >>> 'today)
> > >>> +
> > >>>  (add-option
> > >>>   (gnc:make-multichoice-callback-option
> > >>>gnc:pagename-general optname-period
> > >>> @@ -1107,6 +1110,22 @@ also show overall period profit & loss."))
> > >>> retained-earnings-fn
> > >>>   #:negate-amounts? #t)
> > >>>
> > >>> +(add-to-table multicol-table-right (_

Re: [GNC-dev] Feedback on GnuCash 3.903

[Christopher Lam]

Good luck. I've just verified that the old (3.x) balance-sheet date
defaults to "end-of-accounting-period", so, the first few lines shouldn't
be added.

On Thu, 4 Jun 2020 at 15:41, mark sattolo  wrote:

>
> Thanks. I'll give it a try. I'll just update the source in my git folder
> for tag 3.903 and rebuild if I can't figure out how to modify the flatpak.
>
> *Mark Sattolo*
> *mh.sa...@gmail.com *
> *(613) 447-5385*
>
>
> On Thu, Jun 4, 2020 at 11:36 AM Christopher Lam 
> wrote:
>
>> Hi Mark
>>
>> The reports for balance-sheet and income-statement were replaced with the
>> multicolumn ones. See the release notes. This was described in devel a few
>> weeks/months ago.
>>
>> Try the following patch which will reduce the discrepancy in the default
>> options between old and new. You may be able to modify the patch from
>> within the flatpak (but I'm not sure).
>>
>> modified   gnucash/report/reports/standard/balsheet-pnl.scm
>> @@ -176,6 +176,9 @@ also show overall period profit & loss."))
>>  (gnc:options-add-date-interval!
>>   options gnc:pagename-general optname-startdate optname-enddate "c")
>>
>> +(gnc:option-set-default-value
>> + (gnc:lookup-option options gnc:pagename-general optname-enddate)
>> 'today)
>> +
>>  (add-option
>>   (gnc:make-multichoice-callback-option
>>gnc:pagename-general optname-period
>> @@ -1107,6 +1110,22 @@ also show overall period profit & loss."))
>> retained-earnings-fn
>>   #:negate-amounts? #t)
>>
>> +(add-to-table multicol-table-right (_ "Liability and Equity")
>> +  (append liability-accounts
>> +  equity-accounts
>> +  (if common-currency
>> +  (list (vector (_ "Unrealized Gains")
>> +unrealized-gain-fn))
>> +  '())
>> +  (if (null? income-expense)
>> +  '()
>> +  (list (vector (_ "Retained Earnings")
>> +retained-earnings-fn
>> +  #:negate-amounts? #t
>> +  #:show-title? #f
>> +  #:show-accounts? #f
>> +  #:show-total? #t)
>> +
>>  (if (and common-currency show-rates?)
>>  (add-to-table multicol-table-right (_ "Exchange Rates")
>>asset-liability
>>
>> On Thu, 4 Jun 2020 at 15:18, mark sattolo  wrote:
>>
>>> I am on Linux Mint 19.3 Cinnamon. I started using Gnc 3.903 yesterday
>>> morning. This is a version I built from git using tag '3.903' on June 2.
>>> It
>>> built without any problems, so I assumed it was good, but now it occurs
>>> to
>>> me that all these problems may just be due to a problem with my build.
>>> But
>>> I thought i would report now anyway just in case there are general issues
>>> with this version. I was actually going to try a flatpak build of 3.903,
>>> but I couldn't tell from any of the build names in Gnucash flatpak repo
>>> <https://code.gnucash.org/builds/flatpak/> which one is for version
>>> 3.903.
>>>
>>> Anyway, everything seemed fine with 3.903 until I opened one of my saved
>>> reports. The appearance of the report was essentially unrecognizable. I
>>> only ever use my saved reports and their appearance hasn't changed for
>>> years, for any other Gnucash version (release or maint) until 3.903. So I
>>> went in to the report *options* to see if I could restore the layout to
>>> what i was used to:
>>>
>>> Commodities tab:
>>> there is a new Common Currency checkbox at the top, which was unchecked,
>>> and everything below was greyed out. But the two checkboxes 'Show
>>> original
>>> currency amount' and 'Show exchange rates' were both checked, even though
>>> in my original options, the previous two checkboxes on this tab: 'Show
>>> foreign currencies' and 'Show exchange rates' were both saved as
>>> *unchecked*.
>>> So, checking the Common Currency box to ungrey the other options and then
>>> unchecking the currency and 

Re: [GNC-dev] Feedback on GnuCash 3.903

[Christopher Lam]

Oops better patch below:

--snip--
modified   gnucash/report/reports/standard/balsheet-pnl.scm
@@ -176,6 +176,9 @@ also show overall period profit & loss."))
 (gnc:options-add-date-interval!
  options gnc:pagename-general optname-startdate optname-enddate "c")

+(gnc:option-set-default-value
+ (gnc:lookup-option options gnc:pagename-general optname-enddate)
+ (cons 'relative 'today))
+
 (add-option
  (gnc:make-multichoice-callback-option
   gnc:pagename-general optname-period
@@ -1107,6 +1110,22 @@ also show overall period profit & loss."))
retained-earnings-fn
  #:negate-amounts? #t)

+(add-to-table multicol-table-right (_ "Liability and Equity")
+  (append liability-accounts
+  equity-accounts
+  (if common-currency
+  (list (vector (_ "Unrealized Gains")
+unrealized-gain-fn))
+  '())
+  (if (null? income-expense)
+  '()
+  (list (vector (_ "Retained Earnings")
+retained-earnings-fn
+  #:negate-amounts? #t
+  #:show-title? #f
+  #:show-accounts? #f
+  #:show-total? #t)
+
 (if (and common-currency show-rates?)
 (add-to-table multicol-table-right (_ "Exchange Rates")
   asset-liability

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

Re: [GNC-dev] Feedback on GnuCash 3.903

[Christopher Lam]

Hi Mark

The reports for balance-sheet and income-statement were replaced with the
multicolumn ones. See the release notes. This was described in devel a few
weeks/months ago.

Try the following patch which will reduce the discrepancy in the default
options between old and new. You may be able to modify the patch from
within the flatpak (but I'm not sure).

modified   gnucash/report/reports/standard/balsheet-pnl.scm
@@ -176,6 +176,9 @@ also show overall period profit & loss."))
 (gnc:options-add-date-interval!
  options gnc:pagename-general optname-startdate optname-enddate "c")

+(gnc:option-set-default-value
+ (gnc:lookup-option options gnc:pagename-general optname-enddate)
'today)
+
 (add-option
  (gnc:make-multichoice-callback-option
   gnc:pagename-general optname-period
@@ -1107,6 +1110,22 @@ also show overall period profit & loss."))
retained-earnings-fn
  #:negate-amounts? #t)

+(add-to-table multicol-table-right (_ "Liability and Equity")
+  (append liability-accounts
+  equity-accounts
+  (if common-currency
+  (list (vector (_ "Unrealized Gains")
+unrealized-gain-fn))
+  '())
+  (if (null? income-expense)
+  '()
+  (list (vector (_ "Retained Earnings")
+retained-earnings-fn
+  #:negate-amounts? #t
+  #:show-title? #f
+  #:show-accounts? #f
+  #:show-total? #t)
+
 (if (and common-currency show-rates?)
 (add-to-table multicol-table-right (_ "Exchange Rates")
   asset-liability

On Thu, 4 Jun 2020 at 15:18, mark sattolo  wrote:

> I am on Linux Mint 19.3 Cinnamon. I started using Gnc 3.903 yesterday
> morning. This is a version I built from git using tag '3.903' on June 2. It
> built without any problems, so I assumed it was good, but now it occurs to
> me that all these problems may just be due to a problem with my build. But
> I thought i would report now anyway just in case there are general issues
> with this version. I was actually going to try a flatpak build of 3.903,
> but I couldn't tell from any of the build names in Gnucash flatpak repo
>  which one is for version 3.903.
>
> Anyway, everything seemed fine with 3.903 until I opened one of my saved
> reports. The appearance of the report was essentially unrecognizable. I
> only ever use my saved reports and their appearance hasn't changed for
> years, for any other Gnucash version (release or maint) until 3.903. So I
> went in to the report *options* to see if I could restore the layout to
> what i was used to:
>
> Commodities tab:
> there is a new Common Currency checkbox at the top, which was unchecked,
> and everything below was greyed out. But the two checkboxes 'Show original
> currency amount' and 'Show exchange rates' were both checked, even though
> in my original options, the previous two checkboxes on this tab: 'Show
> foreign currencies' and 'Show exchange rates' were both saved as
> *unchecked*.
> So, checking the Common Currency box to ungrey the other options and then
> unchecking the currency and exchange rate boxes, restored the layout of the
> report to basically what I was familiar with, as it no longer had long
> lists of commodities under essentially every sub-total.
>
> General tab:
> the report I was looking at, which I run often, is a balance sheet for all
> my accounts, for date 'Today'. The old options had a select list titled
> 'Balance sheet date' which was set to the relative date of Today. The new
> options have a Start Date and an End Date. The Start Date is greyed out, so
> I guess it is fairly easy to figure out that since it doesn't make sense to
> have two dates for a Balance, that the End Date is the active one.
> Unfortunately, the date shown in 'End Date' was not 'Today' but had been
> changed to 'End of accounting period'... So I changed it back to 'Today' to
> get the proper balance date as it had been before.
>
> Other problems:
> 1) There used to be a final total for the credit side of 'Total Liabilities
> and Equity', which would match the Total Assets line if the balance was
> done properly (sometimes it doesn't balance which means that I have created
> some new accounts in the meantime and have to update the saved config), but
> this line was missing and I tried every option I could find to restore it,
> but nothing worked. Which means to ensure your balance is actually working,
> you have to add on your own the Total Liability and Total Equity lines and
> compare this to Total Assets.
> So, just from looking, I could tell th

[GNC-dev] Unposted invoices == quotes?

[Christopher Lam]

https://bugs.gnucash.org/show_bug.cgi?id=797769

Invoices which exist but are not posted may be interpreted as "quotes".
Does anyone have any particular views? Internally it all works out; the
main changes will be in the UI, report code, and documentation.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Fwd: gnucash master: Multiple changes pushed

[Christopher Lam]

Small warning/notice is warranted:
This will automatically modify datafile to add feature as follows.

  
Register sort and filter settings stored in .gcm
file
Store the register sort and filter
settings in .gcm metadata file (requires at least GnuCash 3.3)
  

-- Forwarded message -
From: Robert Fewell 
Date: Thu, 14 May 2020 at 09:36
Subject: gnucash master: Multiple changes pushed
To: 


Updated  via  https://github.com/Gnucash/gnucash/commit/6fb50d22 (commit)
 via  https://github.com/Gnucash/gnucash/commit/bf9c4441 (commit)
 via  https://github.com/Gnucash/gnucash/commit/b6de2981 (commit)
 via  https://github.com/Gnucash/gnucash/commit/2494ad1a (commit)
 via  https://github.com/Gnucash/gnucash/commit/74abd821 (commit)
 via  https://github.com/Gnucash/gnucash/commit/4c8ebfe1 (commit)
 via  https://github.com/Gnucash/gnucash/commit/2f5225ad (commit)
 via  https://github.com/Gnucash/gnucash/commit/b622518f (commit)
from  https://github.com/Gnucash/gnucash/commit/a874483b (commit)



commit 6fb50d227a2a07acdfcf30194a949239bdb32ad3
Author: Robert Fewell <14ubo...@gmail.com>
Date:   Sat May 2 14:45:14 2020 +0100

Complete the move of saving register filter/sort to .gcm

This commit changes the saving of register filter and sort information
from KVP entries to using the .gcm file. On register load these
settings are transferred to the .gcm file and the KVP entries removed.
A feature flag is also set when the first register is loaded by this
version.

diff --git a/gnucash/gnome/gnc-plugin-page-register.c
b/gnucash/gnome/gnc-plugin-page-register.c
index 36ff606ac..5229de385 100644
--- a/gnucash/gnome/gnc-plugin-page-register.c
+++ b/gnucash/gnome/gnc-plugin-page-register.c
@@ -730,6 +730,10 @@ gnc_plugin_page_register_new_common (GNCLedgerDisplay*
ledger)
 gchar* label_color;
 QofQuery* q;

+// added for version 4.0 onwards
+if (!gnc_features_check_used (gnc_get_current_book(),
GNC_FEATURE_REG_SORT_FILTER))
+gnc_features_set_used (gnc_get_current_book(),
GNC_FEATURE_REG_SORT_FILTER);
+
 /* Is there an existing page? */
 gsr = gnc_ledger_display_get_user_data (ledger);
 if (gsr)
@@ -1656,10 +1660,6 @@ static const gchar* style_names[] =
 #define KEY_REGISTER_STYLE  "RegisterStyle"
 #define KEY_DOUBLE_LINE "DoubleLineMode"

-#define KEY_PAGE_SORT   "register_order"
-#define KEY_PAGE_SORT_REV   "register_reversed"
-#define KEY_PAGE_FILTER "register_filter"
-
 #define LABEL_ACCOUNT   "Account"
 #define LABEL_SUBACCOUNT"SubAccount"
 #define LABEL_GL"GL"
@@ -2061,6 +2061,18 @@ gnc_plugin_page_register_get_tab_color
(GncPluginPage* plugin_page)
 return g_strdup (color ? color : "Not Set");
 }

+static void
+gnc_plugin_page_register_check_for_empty_group (GKeyFile *state_file,
const gchar *state_section)
+{
+gsize num_keys;
+gchar **keys = g_key_file_get_keys (state_file, state_section,
&num_keys, NULL);
+
+if (num_keys == 0)
+gnc_state_drop_sections_for (state_section);
+
+g_strfreev (keys);
+}
+
 static const gchar*
 gnc_plugin_page_register_get_filter_gcm (Account* leader)
 {
@@ -2094,7 +2106,6 @@ gnc_plugin_page_register_get_filter (GncPluginPage*
plugin_page)
 {
 GncPluginPageRegisterPrivate* priv;
 GNCLedgerDisplayType ledger_type;
-GNCLedgerDisplay* ld;
 Account* leader;
 const char* filter = NULL;

@@ -2102,19 +2113,12 @@ gnc_plugin_page_register_get_filter (GncPluginPage*
plugin_page)
   _ ("unknown"));

 priv = GNC_PLUGIN_PAGE_REGISTER_GET_PRIVATE (plugin_page);
-ld = priv->ledger;
-ledger_type = gnc_ledger_display_type (ld);
-leader = gnc_ledger_display_leader (ld);

-// load from gcm file for LD_GL or when feature is set
-if (ledger_type == LD_GL ||
-gnc_features_check_used (gnc_get_current_book(),
GNC_FEATURE_REG_SORT_FILTER))
-filter = gnc_plugin_page_register_get_filter_gcm (leader);
-else // load from kvp
-{
-if ((ledger_type == LD_SINGLE) || (ledger_type == LD_SUBACCOUNT))
-filter = xaccAccountGetFilter (leader);
-}
+ledger_type = gnc_ledger_display_type (priv->ledger);
+leader = gnc_ledger_display_leader (priv->ledger);
+
+// load from gcm file
+filter = gnc_plugin_page_register_get_filter_gcm (leader);

 return filter ? g_strdup (filter) : g_strdup_printf ("%s,%s,%s,%s",
  DEFAULT_FILTER,
@@ -2137,6 +2141,8 @@ gnc_plugin_page_register_set_filter_gcm (Account*
leader, const gchar* filter,
 {
 if (g_key_file_has_key (state_file, state_section,
KEY_PAGE_FILTER, NULL))
 g_key_file_remove_key (state_file, state_section,
KEY_PAGE_FILTER, NULL);
+
+gnc_plugin_page_register_check_for_empty_group (state_file,
state_section);
 }
 else
 {
@

Re: [GNC-dev] gnucash master: Multiple changes pushed

[Christopher Lam]

Hi the branch name was originally 'maint-'. Github doesn't allow changing
branch names without creating a new PR. So, next time I'll just need to
amend the merge commit message (and also add a #link to PR).

On Wed, 13 May 2020 at 12:21, Geert Janssens 
wrote:

> Op woensdag 13 mei 2020 14:17:20 CEST schreef Geert Janssens:
> > Op dinsdag 12 mei 2020 16:06:05 CEST schreef Christopher Lam:
> > > Updated  via  https://github.com/Gnucash/gnucash/commit/57fe0515
> (commit)
> > >
> > >  via  https://github.com/Gnucash/gnucash/commit/b4d7386d (commit)
> > >
> > > from  https://github.com/Gnucash/gnucash/commit/ebd9db89 (commit)
> > >
> > > commit 57fe05156535bc67960b2497393cf8eee3525a73
> > > Merge: ebd9db892 b4d7386d4
> > > Author: Christopher Lam 
> > > Date:   Tue May 12 21:47:36 2020 +0800
> > >
> > >     Merge branch 'maint-trep-case-insensitive' PR #719
> > >
> > > commit b4d7386d44122384c036ae68c1a090bc36210389
> > > Author: Christopher Lam 
> > > Date:   Mon May 11 20:51:21 2020 +0800
> > >
> > > [trep-engine] "Transaction Filter is case insensitive"
> > >
> > > add Filter option to make Transaction Filter case insensitive.
> > >
> > > Summary of changes:
> > >  .../reports/standard/test/test-transaction.scm | 16 
> > >  gnucash/report/trep-engine.scm | 29
> > >
> > > ++ 2 files changed, 40 insertions(+), 5
> deletions(-)
> > >
> > > ___
> > > gnucash-patches mailing list
> > > gnucash-patc...@gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-patches
> >
> > This commit merges some of your local maint changes into public master.
> > However that commit in question hasn't been pushed to maint yet as far
> as I
> > can see. Is that intentional ?
> >
> > Geert
>
> Ok, on the PR I see John asked to merge it into master only. To avoid
> confusion, please change the feature branch name before doing so. The fact
> it
> mentions "maint-" set me on the wrong track. Or at the very least motivate
> the
> branch change in the merge commit.
>
> Regards,
>
> Geert
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About Experimental Reports

[Christopher Lam]

Any further preferences or opinions onto the fate of old vs experimental
reports swapping places? I personally don't mind keeping the status quo;
the senior devs suggested the swap. Old reports can either be removed
completely or hidden into the --extras flag until 5.x.

On Tue, 28 Apr 2020, 3:25 am Christopher Lam, 
wrote:

> Saved configurations, the following can apply:
>
> Most relevant options are transferred unchanged eg account selection,
> dates chosen.
>
> Options which are not present in upgraded reports are ignored.
>
> New options are set to a useful value by default.
>
> The layout of most upgraded reports will be slightly different.
>
> There is no 100% valid upgrade strategy that will satisfy all users.
>
> On Tue, 28 Apr 2020, 12:08 am Adrien Monteleone, <
> adrien.montele...@lusfiber.net> wrote:
>
>> What happens to saved configs of old reports?
>>
>> Does GC choke when you try to run one?
>>
>> Is an error message generated?
>>
>> If the reports are renamed (and maybe relocated) will this auto-map so
>> the configs still work? Or will that just blow them up entirely anyway?
>>
>> I’ll presume the configs won’t work on new reports since some options
>> either won’t exist or have been changed.
>>
>> I rarely run a default report except for testing or to see what a new
>> user sees when they need help or someone thinks they found a bug. For my
>> own use I have customized configs. (not so many I can’t re-create them, but
>> it will be some effort to figure out how to re-create those reports with
>> the new versions) I’m sure some users out there have extensive saved
>> configs.
>>
>> Regards,
>> Adrien
>>
>> > On Apr 24, 2020 w17d115, at 10:08 PM, Christopher Lam <
>> christopher@gmail.com> wrote:
>> >
>> > Dear Users
>> >
>> > We hope the revamped reports have been useful and welcome to the
>> community.
>> >
>> > With 4.0 round the corner, it is time to consider replacing the old
>> reports
>> > with the experimental ones.
>> >
>> > Balance Sheet and Income Statement (Multicolumn) reports are now well
>> > tested, and can replace the previous ones; however not all options will
>> or
>> > can survive the merge. This means most options will remain unchanged
>> > - accounts selection
>> > - target report currency (optional in new report)
>> > - some display options
>> >
>> > and obsolete options ignored/renamed e.g.:
>> > - asset/liability/equity individual labels/totals
>> > - accounting style rules
>> > - too many subtotal options
>> >
>> > Also the various business reports Customer/Employee/Vendor reports and
>> > Aging reports are now upgraded, and can supplant the old reports
>> > immediately. The newer reports do NOT need to specify an AP/AR account,
>> and
>> > can show related business transactions.
>> >
>> > The question is how to handle old reports: hide (behind a seldom-used
>> > --extras argument), rename, or remove altogether. Any preference?
>> > ___
>> > gnucash-devel mailing list
>> > gnucash-devel@gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >
>>
>>
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] RegEx Case insensitive Search via Reports > Transaction Report > Transaction Filter ?

[Christopher Lam]

Not currently in the transaction report though. An easy upgrade is possible.

On Mon, 11 May 2020, 11:37 am John Ralls,  wrote:

>
>
> > On May 10, 2020, at 6:26 PM, Christopher Lam 
> wrote:
> >
> > I think this would be a worthwhile upgrade for the transaction report?
> >
> > -- Forwarded message -
> > From: Christopher Lam 
> > Date: Sun, 10 May 2020, 5:44 am
> > Subject: Re: [GNC] RegEx Case insensitive Search via Reports >
> Transaction
> > Report > Transaction Filter ?
> > To: Fran_3 
> > Cc: Gnucash Users 
> >
> >
> > You'll need to use [Gg][Oo][Dd][Aa][Dd][Dd][Yy]
> >
>
> Why isn't it already there? It's in the Find dialog already with a "match
> case" checkbox.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Fwd: [GNC] RegEx Case insensitive Search via Reports > Transaction Report > Transaction Filter ?

[Christopher Lam]

I think this would be a worthwhile upgrade for the transaction report?

-- Forwarded message -
From: Christopher Lam 
Date: Sun, 10 May 2020, 5:44 am
Subject: Re: [GNC] RegEx Case insensitive Search via Reports > Transaction
Report > Transaction Filter ?
To: Fran_3 
Cc: Gnucash Users 


You'll need to use [Gg][Oo][Dd][Aa][Dd][Dd][Yy]

On Sat, 9 May 2020 at 16:06, Fran_3 via gnucash-user <
gnucash-u...@gnucash.org> wrote:

> When using Reports > Transaction Report
> I want to use the Transaction Filter to do a case insensitive search for
> some word like, for instance ... godaddy
> I'm searching the Check Register but do not want use the Ctl-F search as
> it always returns each transaction as a split.
> I tried
> (?i)godaddy
> in the Transaction Filter field but get nothing...
> The target word may be entered into the system in many ways
> GODADDYGodaddyGoDaddyetc
> Thanks for any help.
>
>
>
>
>
>
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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: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
> > positive numbers and the other with negative numbers.
> >
>
> It is. What's not reasonable is to have a preference (as opposed to a book
> option) that changes which is negative, especially for stored values. Even
> having a book option is dicey unless that option affects exactly one place
> in all of GnuCash's code base.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Transaction matcher, code to detect many-to-one matches?

[Christopher Lam]

It's very non-trivial. Consider simplified examples:

OFX
02/01/20 DESC $25
04/01/20 DESC $25
06/01/20 DESC $25

Account
01/01/20 DESC $25
03/01/20 DESC $25
03/01/20 DESC $25
05/01/20 DESC $29

They all could match each other. There's always a score that exists between
any OFX-split and Account-split. eg the first splits will have a high
score, and the last lines will have a low score due to the amount
discrepancy. The automatcher should prepare a match list that maximises the
"good" matches e.g. 02/01/20(OFX) to 01/01/20(account), and does not
attempt matches below an arbitrary threshold e.g. 04/01/20(OFX) to
05/01/20(account).

The answer will lie somewhere in
https://en.wikipedia.org/wiki/Matching_(graph_theory)

C

On Thu, 7 May 2020, 12:46 pm jeanl,  wrote:

> What about this question?
>
> On a related note, is it expected that an already-cleared transactions
> should appear in the list of matches, if the "Enable update match action"
> option isn't on? It seems that it shouldn't but maybe I don't quite
> understand the match logic...
>
> Jean
>
>
>
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 reversal strategy chosen in the
> preferences. The result is
> that the data in your book will be interpreted *differently* depending on
> the value of that
> preference when saving or loading your book. That is very bad and the sole
> reason this change
> was proposed in the first place.
>

For a regular budget month, let's allocate $400 income to: $100 general
expenses, $200 pay back home loan, $100 savings.
Internally they are currently represented as: income=400,expenses=200,
loan=-200, savings=100.

As Phil reports; income-expenses-assets+liability = 0.
The more consistent approach is: income=-400, expense=200, loan=200,
savings=100.

We can't fix this for 3.x as this is a data format change. However what we
> are trying for 3.x is to
> limit the damage by some code tweaks. I don't remember all the details as
> I'm not the one
> doing this work. It has something to do however with fixing the
> interpretation for one specific
> sign reversal strategy (which looks like it covers most of the cases).
>

The pending work is at https://github.com/Gnucash/gnucash/pull/585 and
performs a one time sign conversion. It will offer scan the budget amounts,
make an educated guess at the sign-reversal strategy in use, heavily biased
towards using credit-accounts. Then sets a feature flag to trigger the
newer code path and prevent writing datafile by versions prior to 3.8, and
prompt the user to recheck all budgets. If the user elects to delay the
sign conversion, the budget will be read only until the conversion is run.

*But all of this will be stalled until the current budget viewer is
thoroughly debugged.*
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 has changed. This way we can be much more certain that a
change is acceptable before considering merge onto the mainline builds.
BTW thanks warlord.

On Tue, 28 Apr 2020 at 11:33, Phil Longstaff 
wrote:

> 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, <
> > 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
> > > 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 app already throws people at
> > > least in the middle of the pool of accounting. Being consistent with
> > > accounting text resources might reduce confusion. (in my humble
> opinion)
> > If
> > > texts don’t refer to credit accounts as ’normally negative’, or don’t
> > > address or present ’sign’ at all, then people learning on their own
> would
> > > come to GnuCash and see a similar approach.
> > >
> > > I presently have my reversed balance accounts setting to ‘Credit
> > accounts’
> > > because that way, negative values tell me I have a contra-account
> > balance.
> > > Short of seeing the balance as Dr. or Cr., that’s the best I can get at
> > the
> > > moment.
> > >
> > > Christopher,
> > >
> > > I’ll add a big ’Thank You’ for tackling this. I understand you have
> > > program constraints to work in and can’t re-build the house for the
> > kitchen
> > > sink. Even if it isn't the optimum, if it is at least consistent and
> > works
> > > properly, that is better than not.
> > >
> > > Regards,
> > > Adrien
> > >
> > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff <
> > > phil.longst...@gmail.com> wrote:
> > > >
> > > > 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 negative value.
> > > >
> > > > I understand what you are saying about budget outlays always being
> > > > positive. That also makes sense. However, it doesn't match what
> gnucash
> > > > currently does.
> > > >
> > > > Yes, it would be more straightforward to budget either a CR or a DB,
> > and
> > > > then "amount left to budget" would be sum(DB) - sum(CR). However,
> that
> > > > would make it more confusing for non-accountants.
> > >
> > >
> > > ___
> > > gnucash-devel mailing list
> > > gnucash-devel@gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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
> 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 app already throws people at
> least in the middle of the pool of accounting. Being consistent with
> accounting text resources might reduce confusion. (in my humble opinion) If
> texts don’t refer to credit accounts as ’normally negative’, or don’t
> address or present ’sign’ at all, then people learning on their own would
> come to GnuCash and see a similar approach.
>
> I presently have my reversed balance accounts setting to ‘Credit accounts’
> because that way, negative values tell me I have a contra-account balance.
> Short of seeing the balance as Dr. or Cr., that’s the best I can get at the
> moment.
>
> Christopher,
>
> I’ll add a big ’Thank You’ for tackling this. I understand you have
> program constraints to work in and can’t re-build the house for the kitchen
> sink. Even if it isn't the optimum, if it is at least consistent and works
> properly, that is better than not.
>
> Regards,
> Adrien
>
> > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff <
> phil.longst...@gmail.com> wrote:
> >
> > 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 negative value.
> >
> > I understand what you are saying about budget outlays always being
> > positive. That also makes sense. However, it doesn't match what gnucash
> > currently does.
> >
> > Yes, it would be more straightforward to budget either a CR or a DB, and
> > then "amount left to budget" would be sum(DB) - sum(CR). However, that
> > would make it more confusing for non-accountants.
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About Experimental Reports

[Christopher Lam]

Saved configurations, the following can apply:

Most relevant options are transferred unchanged eg account selection, dates
chosen.

Options which are not present in upgraded reports are ignored.

New options are set to a useful value by default.

The layout of most upgraded reports will be slightly different.

There is no 100% valid upgrade strategy that will satisfy all users.

On Tue, 28 Apr 2020, 12:08 am Adrien Monteleone, <
adrien.montele...@lusfiber.net> wrote:

> What happens to saved configs of old reports?
>
> Does GC choke when you try to run one?
>
> Is an error message generated?
>
> If the reports are renamed (and maybe relocated) will this auto-map so the
> configs still work? Or will that just blow them up entirely anyway?
>
> I’ll presume the configs won’t work on new reports since some options
> either won’t exist or have been changed.
>
> I rarely run a default report except for testing or to see what a new user
> sees when they need help or someone thinks they found a bug. For my own use
> I have customized configs. (not so many I can’t re-create them, but it will
> be some effort to figure out how to re-create those reports with the new
> versions) I’m sure some users out there have extensive saved configs.
>
> Regards,
> Adrien
>
> > On Apr 24, 2020 w17d115, at 10:08 PM, Christopher Lam <
> christopher@gmail.com> wrote:
> >
> > Dear Users
> >
> > We hope the revamped reports have been useful and welcome to the
> community.
> >
> > With 4.0 round the corner, it is time to consider replacing the old
> reports
> > with the experimental ones.
> >
> > Balance Sheet and Income Statement (Multicolumn) reports are now well
> > tested, and can replace the previous ones; however not all options will
> or
> > can survive the merge. This means most options will remain unchanged
> > - accounts selection
> > - target report currency (optional in new report)
> > - some display options
> >
> > and obsolete options ignored/renamed e.g.:
> > - asset/liability/equity individual labels/totals
> > - accounting style rules
> > - too many subtotal options
> >
> > Also the various business reports Customer/Employee/Vendor reports and
> > Aging reports are now upgraded, and can supplant the old reports
> > immediately. The newer reports do NOT need to specify an AP/AR account,
> and
> > can show related business transactions.
> >
> > The question is how to handle old reports: hide (behind a seldom-used
> > --extras argument), rename, or remove altogether. Any preference?
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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-amounts whereby account-type is
bank/cash/loan; i.e. it only tallies account-type asset/liability/etc. I
*think* this should be fixed. Any ideas?

Derek has kindly agreed to create regular flatpak builds for me and these
builds need testing. It is very difficult to fix the above without adequate
testers using their existing budgets. The next candidate will be available
in https://code.gnucash.org/builds/flatpak/christopherlam/beta/ (after
27/4/2020)

Your YTD feature has been replicated in the existing budget report - see
General / use accumulated amounts

Summing children accounts will always be difficult because children
accounts may have an incompatible account type.

On Mon, 27 Apr 2020 at 11:34, Phil Longstaff 
wrote:

> 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 with a positive value for that month for that account.
> If I want to plan to pull money from savings (e.g. a retirement savings
> fund), I will have a budget with a negative value for that month for that
> account.
>
> For Liabilities, it is similar.
>
> If I plan to pay off part of a loan or line of credit, I will have a budget
> with a negative value for that month for that account.
> If I plan to increase the value of a loan or line of credit, I will have a
> budget with a positive value for that month for that account.
>
> In other words, positive value increase an asset or liability, and negative
> values decrease them.
>
> In this case, the room left in my budget is Income - Expenses - Assets +
> Liabilities.
>
> If I can speak to the budget report for a minute, there are 2 things I see:
>
> 1) I miss the ability to see YTD. A few years ago, I created a report which
> had 3 sets of columns: current month, YTD, and total year. I find YTD
> useful because for some accounts, I may have an idea of the total budget
> for the year, but do not know the timing. I can then either allocate the
> whole budget to one month (January? December? July?) or split it evenly
> across all months. I usually split it. An example is car maintenance. I
> know that my car will need about $X repairs for the typical year, but I
> don't know when the repairs will be. I allocate $X/12 for each month. If I
> put the entire value $X in 1 month, it gives me a skewed idea for my budget
> room for that month. Putting $X/12 for each month, it is easier to see that
> some months, income > expenses, and for other months, income < expenses,
> but for the year, it evens out. I use YTD and Total Year columns to see how
> well this evening out is working.
>
> 2) For parent rows, I would like to see the budget and actual values show
> the sum of the selected children, not all children. I may wish to produce a
> budget report for a subset of all of my expense accounts (e.g. my wife's
> and my personal expenses like clothing, haircuts, etc). The problem is that
> the "Expenses" parent line shows the actual value of *all* expenses, not
> just the ones I have selected. This is
> https://bugs.gnucash.org/show_bug.cgi?id=780382. My Scheme is not very
> good, but I will see if I can find some time to look at this one.
>
> Phil
>
> On Mon, Apr 27, 2020 at 12:10 AM Christopher Lam <
> christopher@gmail.com>
> wrote:
>
> > 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.)
> >
> > [image: budget-view.png]
> >
> >
> > On Sun, 19 Apr 2020 at 05:07, Christopher Lam  >
> > wrote:
> >
> > > 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 in zero. This
> > &

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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.)

[image: budget-view.png]


On Sun, 19 Apr 2020 at 05:07, Christopher Lam 
wrote:

> 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 in zero. This
> assumes credit-accounts sign reversal.
> * future methodology is: in a period, all natural budget amounts must
> equal zero. i.e. incomes being negative, will be balanced by positive
> expenses etc.
>
> My plan to try fix this for good is to *remove* all totals except the
> "Remaining to Budget"; from my understanding this is the only total of any
> use.
>
> Alternatively, another plan is to switch to future methodology and forego
> backward compatibility in existing budgets, for use in 4.x or 5.x.
>
> On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
>
>> 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:59 AM, Christopher Lam <
>> christopher@gmail.com> wrote:
>> >
>> > 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, <
>> christopher@gmail.com>
>> > wrote:
>> >
>> >>
>> >>
>> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, <
>> christopher@gmail.com>
>> >> 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
>> >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave
>> appropriately
>> >>>
>> >>
>> >> Addendum this is not simply an arithmetic test; it *must also
>> >> confirm that the totals and signs are sensible for the purpose of
>> >> budgeting. Hence the difficulty of a one person coder to make it work.
>> For
>> >> example, we can budget a liability account regularly until we have
>> enough
>> >> deposit for a huge loan, or we can budget a liability account
>> regularly for
>> >> the loan repayments. IIUC both approaches are "valid" but the signs
>> will be
>> >> opposite. Other counter examples likely exist.
>> >>
>> >> - budget.scm report (optionally other budget reports but these are
>> lower
>> >>> priority) and especially difference column.
>> >>>
>> >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
>> >>> adrien.montele...@lusfiber.net> wrote:
>> >>>
>> >>>> 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 time frame do you
>> >>>> have and is there something in particular you’re looking to find.
>> (other
>> >>>> than just loosely that the totals appear to work)
>> >>>>
>> >>>> Regards,
>> >>>> Adrien
>> >>>>
>> >>>>> On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
>> >>>> christopher@gmail.com> wrote:

[GNC-dev] About Experimental Reports

[Christopher Lam]

Dear Users

We hope the revamped reports have been useful and welcome to the community.

With 4.0 round the corner, it is time to consider replacing the old reports
with the experimental ones.

Balance Sheet and Income Statement (Multicolumn) reports are now well
tested, and can replace the previous ones; however not all options will or
can survive the merge. This means most options will remain unchanged
- accounts selection
- target report currency (optional in new report)
- some display options

and obsolete options ignored/renamed e.g.:
- asset/liability/equity individual labels/totals
- accounting style rules
- too many subtotal options

Also the various business reports Customer/Employee/Vendor reports and
Aging reports are now upgraded, and can supplant the old reports
immediately. The newer reports do NOT need to specify an AP/AR account, and
can show related business transactions.

The question is how to handle old reports: hide (behind a seldom-used
--extras argument), rename, or remove altogether. Any preference?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Fwd: [Gnucash/gnucash] Merge branch 'patch-1' of git://github.com/thetedmunds/gnucash into maint (96a6e1b)

[Christopher Lam]

I think Frank has the right idea to set a pull request merge commit message
to link to the pull request itself. This facilitates researching old
comments. Unless anyone objects I'll add some into recent ones.

-- Forwarded message -
From: Christopher Lam 
Date: Fri, 24 Apr 2020, 8:20 pm
Subject: Re: [Gnucash/gnucash] Merge branch 'patch-1' of git://
github.com/thetedmunds/gnucash into maint (96a6e1b)
To: Gnucash/gnucash 
Cc: Christopher Lam , Your activity <
your_activ...@noreply.github.com>


For future reference: #691 <https://github.com/Gnucash/gnucash/pull/691>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/Gnucash/gnucash/commit/96a6e1b0d5be311bfb2ba0c8213e42d04fb40205#commitcomment-38718448>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPCMPRUMSCIPLYF75L4AKTROF7XHANCNFSM4MQBWCAA>
.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 in zero. This
assumes credit-accounts sign reversal.
* future methodology is: in a period, all natural budget amounts must equal
zero. i.e. incomes being negative, will be balanced by positive expenses
etc.

My plan to try fix this for good is to *remove* all totals except the
"Remaining to Budget"; from my understanding this is the only total of any
use.

Alternatively, another plan is to switch to future methodology and forego
backward compatibility in existing budgets, for use in 4.x or 5.x.

On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> 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:59 AM, Christopher Lam <
> christopher@gmail.com> wrote:
> >
> > 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, <
> christopher@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, <
> christopher@gmail.com>
> >> 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
> >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
> >>>
> >>
> >> Addendum this is not simply an arithmetic test; it *must also
> >> confirm that the totals and signs are sensible for the purpose of
> >> budgeting. Hence the difficulty of a one person coder to make it work.
> For
> >> example, we can budget a liability account regularly until we have
> enough
> >> deposit for a huge loan, or we can budget a liability account regularly
> for
> >> the loan repayments. IIUC both approaches are "valid" but the signs
> will be
> >> opposite. Other counter examples likely exist.
> >>
> >> - budget.scm report (optionally other budget reports but these are lower
> >>> priority) and especially difference column.
> >>>
> >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
> >>> adrien.montele...@lusfiber.net> wrote:
> >>>
> >>>> 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 time frame do you
> >>>> have and is there something in particular you’re looking to find.
> (other
> >>>> than just loosely that the totals appear to work)
> >>>>
> >>>> Regards,
> >>>> Adrien
> >>>>
> >>>>> On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
> >>>> christopher@gmail.com> wrote:
> >>>>>
> >>>>> 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 <
> >>>> christopher@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> This topic is about budgets.
> >>>>>>
> >>>>>> We now know that budgets are currently inherently flawed: they
> >>>> *assume*
> >>>>>> that sign-reversal = credit-accounts, an

Re: [GNC-dev] reconciliation concept from top view

[Christopher Lam]

On Thu, 16 Apr 2020, 2:57 am Dale Phurrough via gnucash-devel, <
gnucash-devel@gnucash.org> wrote:

> Accounting example:
> On 1 April 2020 the bank and I believe it is the truth that my bank account
> contains $1000. Two days later, I discovered that an additional deposit of
> $500 should have been posted to my account. The bank found their error,
> reissued a statement, and I updated my ledger. Now the bank and I agree
> the truth is my bank account contained $1500 on 1 April 2020.
>

I do not think a bank is ever allowed to amend a statement like this. It's
financial fraud. At most, they may issue a new transaction on the day of
the correction, and offer an adjustment for fees, interest etc also dated
on the day of the correction.



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

Re: [GNC-dev] GnuCash 3.10 Released

[Christopher Lam]

Addendum budget liabilities are still an issue in 3.10; this requires more
beta testers please. This will not be fixed until some experienced users
assist.

The 2020-04-07 build on https://code.gnucash.org/builds/win32/maint/ has my
candidate fix (but has the "too strict" reconciliation) -- I think this
build handles budget liability correctly but will no impose my view without
external confirmation.

Alternatively we can re-revert the suggested fix into the 3.10+ daily
builds and allow bleeding-edge users to feed back. P.S. I generally am
quite happy to use bleeding-edge builds for my regular datafile.

On Sun, 12 Apr 2020 at 00:12, John Ralls  wrote:

>
>
> The GnuCash development team announces GnuCash 3.10, the eleventh release
> of the 3.x stable release series.
> Changes
>
> This is a snap release to reverse the changes to the reconcile window's
> filtering reconciled transactions with a reconcile date after the current
> statement date when computing the starting balance. It seems that many
> users' books have accounts with reconcile dates in the future that were
> suddenly filtered out, creating an incorrect starting balance and making it
> impossible to reconcile the book.
>
> Between 3.9 and 3.10, the following bugfixes were accomplished:
>
> Bug 620848 - Transfer Funds window - add Notes field
> Bug 797006 - Balance is misleading in open subaccounts when different
> currencies are involved
> Bug 797318 - Amounts ending in zero displayed as fractions
> Bug 797666 - libgnucash/engine/test/test-recurrence.c: In function
> 'check_valid': 'result' may be used uninitialized
> Bug 797676 - Register displays amount in transaction currency instead
> of register currency.
> Bug 797674 - 3.9: "test-gnc-path-util" failed on Debian amd64
>
> The following fixes and improvements were not associated with bug reports:
>
> Update latest translation from the Translation project.
> [window-reconcile] when reconciling, warn on splits having a reconcile
> date > statement_date
> [window-reconcile] when inputing statement_date, warn if it's after
> today
> [find-transactions] add search for reconciled date
> Show transaction value, not amount, for registers with subaccounts.
>
> If the register has subaccounts in different currencies and a
> transaction has splits in more than one, the transaction will incorrectly
> appear to be unbalanced if we total amounts because the balancing logic
> works on split values.
> Add instance argument to Session constructor
>
> Enables a python console to connect to the running GnuCash's session.
> Make python console less noisy without --debug.
> Provide locals and globals of calling context to the python console's
> shell on shell init
> Merge Jean Laroche's '797006_subaccounts' into maint.
> Add check to display warning dialog for mismatched commodities
> Replicate changes in *2 files
> Apply astyle to modified files
> Merge Chris Mayo's iPython-fixes into maint.
> Make pycons/ishell.py compatible with Python 3 and current IPython
> [eguile-utilities] Prevent crash in balsheet-eg.scm
> [eguile] escape-html -> gnc:html-string-sanitize
> [qif-to-gnc] Properly mark intra-QIF internal transfers.
>
> We have a revised Ukrainian translation.
> Known Issues
>
> The following are open bug reports to the 3.x series considered
> significant by the development team:
>
> Bug 795383 - Gnucash crashes on import of a 1400-transaction (or more)
> CSV file
> Bug 796955 - Import CSV - Single-line two-currency transactions can't
> be imported
> Bug 796992 - gnucash --add-price-quotes can't parse drive letters on
> Windows.
> Bug 796997 - Currency Conversion Dialog appears when recording
> transactions between same currency accounts.
> Bug 797037 - Counter formats not saving
> Bug 797064 - crash when try print report
> Bug 797083 - Gnucash crashes when trying to rename budget
> Bug 797092 - Save As fails: tries to save to reserved directory if
> path contains spaces
> Bug 797113 - Scrubbing crashes when creating small splits that round
> to value 0.
> Bug 797114 - Fixing an SX due to deleted account stuck in an error loop
> Bug 797115 - Can't 're-activate' an expired SX
> Bug 797211 - Very slow UI - dependent on window size
> Bug 797220 - delete account allows move of all transactions to account
> having non-matching currency
> Bug 797236 - Regression: Reconcile window transaction list resets to
> top when new transaction created in account
> Bug 797264 - 3.5 can't use Chinese IME input
> Bug 797283 - Permanent hang on clicking on report tabs
> Bug 797285 - QIF import fails and then crashes
> Bug 797293 - Crash when import "U+R" or "R"
> Bug 797294 - Billing functions freezing
> Bug 797325 - [Windows 7] Reports with charts will not load
> Bug 797329 - Using Japanese IME to enter transactions results in
> unexpected fiel

Re: [GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

The "purpose" for the "fix" was to allow future features:

1. allow manual reconciliation of an account, using past reconciled_date
and relevant past ending_balance. If my "fix" were applied, it would serve
*me* very well:
(a) If an account, properly reconciled, had an errant split hiding
somewhere caused by fat-finger, I could reconcile from any past bank
statement, verify the balance is correct (or not) and narrow down to the
exact period that contains the errant split.
(b) This was also useful to fix cases where a past split was unreconciled
and needed to be rereconciled -- you could reconcile latest statement and
change the field 'n' to 'y' but its reconciled date would *not* be accurate
anymore because it'd be the latest statement; I meant to reset the split
reconciled_date to be the statement_date.

2. a natural extension of allowing past reconciliation is to store the list
of statement_date and ending_balance somewhere in the account metadata and
retrieve the list in reconcile_window. Hence
https://github.com/Gnucash/gnucash/pull/667 is born.
https://user-images.githubusercontent.com/1975870/77246245-5a1e2d80-6c1d-11ea-8fc3-b2ec34fdb5f9.png
is possible. In my testing, rereconciling past statements is nicely
upgraded.

3. a benefit of maintaining old reconciled_data is that we can now compare
an account's reconciled balances at periodic dates against the stored list,
and loudly report if a balance discrepancy is found. See
https://user-images.githubusercontent.com/1975870/78035104-2c8d5e80-7358-11ea-95bc-feba7f9f2bba.png
-- note the first two lines show reconciliation and account balances match;
the third section show unequal balances and show the relevant splits which
contain an extra one.

So, (1) and (2) are not possible -- rereconciling past statement cannot
currently take place (unless code sets/queries a book property "use strict
reconciled dates"), but I believe (3) is still possible. It won't happen
until 4.x though.

On Fri, 10 Apr 2020 at 18:51, Dale Phurrough via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Yes JR and DA 😄
> Nothing bad or sinister, rather a future opportunity to virtually
> whiteboard the concepts and events surrounding "reconciliation", then
> reviewing what gnucash currently does to see the gaps.
>
> It's comforting to see that it works for so many scenarios, and the
> discussion on this was hardy for change/regression.
> With it reverting to 3.8 behavior, I see all this as a healthy outcome with
> a opportunity for the future. I'll gladly participate in it as I'm a
> regular qif, ofx, manual, multiple currencies reconciler.
>
> On Fri, Apr 10, 2020, 6:43 PM Derek Atkins  wrote:
>
> > Dale,
> >
> > On Fri, April 10, 2020 12:37 pm, John Ralls wrote:
> > >
> > >
> > >> On Apr 10, 2020, at 8:22 AM, Dale Phurrough via gnucash-devel
> > >>  wrote:
> > >>
> > >> This feels like a separation of accounting logic -- separate from
> > >> storage
> > >> field -- has broken down. From what you wrote, it seems each of these
> > >> sources have direct access to core fields without any
> > >> accounting/business
> > >> logic to control the transaction of reconciliation nor to validate the
> > >> input into that reconciliation.
> > >
> > > Unfortunately there is very little such separation anywhere in GnuCash.
> >
> > Even moreso, in many cases (e.g. Import) the data just isn't there!  QIF
> > has a reconcile flag but does not contain a reconcile date field. So if
> > you're importing reconciled data, what should you use for the reconciled
> > date?  Over time, different developers working in different parts of the
> > code made slightly different decisions, because at the time the actual
> > date didn't matter because nothing used it.
> >
> > -derek
> >
> > --
> >Derek Atkins 617-623-3745
> >de...@ihtfp.com www.ihtfp.com
> >Computer and Internet Security Consultant
> >
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

Some further findings. I don't think the "fix" needs to come back.

The reconciled_date field is not well defined in code
- during manual reconciliation (which I use heavily) it sets
reconciled_date to statement_date.
- during QIF import from Quicken, it can also set reconcile_status to
mirror Quicken reconcile status, but the reconciled_date is never set at
all, and is interpreted as 01/01/70. These splits would be counted
correctly if my "fix" were reinstated.
- during QIF imports from banks (I use occasionally) the importer doesn't
typically set splits as reconciled but 'c'leared instead
- during OFX import from bank (I use this heavily) splits are set 'c'leared.
- during AQBanking import splits' seem to be reconciled to TODAY.

Conclusion: I think a future storage for *reconciled_date *and
*ending_balance* is still possible if it is populated when completing
successful manual reconciliation, and this does not necessarily need the
"fix". It would simply serve as a data integrity report verifying account
reconciled balances are still matching stored balances.

On Thu, 9 Apr 2020 at 23:09, David Cousens  wrote:

> 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 are affected
> by the errors and to identify what the correct date should have been. While
> this is not as much of a concern for users using GnuCash for their personal
> finances, those using it for business uses may have external requirements
> imposed on them which may for example require verification of
> reconciliations if they are being audited.
>
> If an auditor examines records which have reconciliation dates that are not
> consistent with the transaction dates it would at the least raise a flag
> with them. This is an unlikely event but if detected is likely to result in
> considerable expenditure for such a user.
>
> I was in the fortunate position of having enough knowledge of how GnuCash
> works, the datafile structure and enough accounting knowledge and also
> having the records of exactly when I did the reconciliations to the account
> which allowed me to determine that there had only been one occurrence of
> entering a statement end date incorrectly and that only the splits to one
> specific file had been affected. My situation could have been far more
> complicated. Some users may have records going back much further than 2016
> in a single file. I was fortunate in that after I retired I started a new
> simplified file for my personal records for my wife and myself.
>
> The average user, and particularly business users who will primarily be
> focussed on their business, is unlikely to be able to fix the XML file and
> many would not feel confident about doing it and the risk of them damaging
> their data file irrepairably is high (although you would clearly be foolish
> to do this without creating one or more backups first).
>
> It is easy to say correct the reconciliation dates and rereconcile but I
> feel it will be necessary to provide users with a means of doing that
> correction in a consistent fashion (this really requires a knowledge of the
> transaction dates and the dates of entering the transaction and whether
> other reconciliation dates are used in splits to the particular account so
> that users can select an appropriate reconciliation date which is at least
> consistent with the other dates in their records.
>
> I would opt for option 2 at this stage along with popup warnings on
> detecting the future reconciliation dates and statement end dates ahead of
> the current date, but by default make the feature turned on for new books
> (these should have no reconciliation dates set - it may be necessary to
> consider if this affects records imported from a previous book or other
> program into a new book) and created in the off state when written into an
> existing book which was created without the feature. The warnings could
> contain a reference to the option i.e. turn it on once you have corrected
> the advance date. I think this will allow all users to continue to function
> while incorporating the function until such time as we have a robust fix
> method in place. Even thess will require considerable code changes in a
> varietyt of areas of the code to get up and running where as the fix
> procedure will also be a fairly major undertaking.
>
> Those who feel they have the necessary skills and knowledge can in the
> meantime repair their files and switch the feature on if they desire.
>
> Unfortunately new options always increase the risk of user confusion but
> the
> above approach may minimise this as the user won't see the feature unless
> they are using a new book or have deliberately chosen to use it after
> repairing their file.
>
> The other obvious thin

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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, 
> 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
>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
>>
>
> Addendum this is not simply an arithmetic test; it *must also
> confirm that the totals and signs are sensible for the purpose of
> budgeting. Hence the difficulty of a one person coder to make it work. For
> example, we can budget a liability account regularly until we have enough
> deposit for a huge loan, or we can budget a liability account regularly for
> the loan repayments. IIUC both approaches are "valid" but the signs will be
> opposite. Other counter examples likely exist.
>
> - budget.scm report (optionally other budget reports but these are lower
>> priority) and especially difference column.
>>
>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
>> adrien.montele...@lusfiber.net> wrote:
>>
>>> 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 time frame do you
>>> have and is there something in particular you’re looking to find. (other
>>> than just loosely that the totals appear to work)
>>>
>>> Regards,
>>> Adrien
>>>
>>> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
>>> christopher@gmail.com> wrote:
>>> >
>>> > 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 <
>>> christopher@gmail.com>
>>> > wrote:
>>> >
>>> >> 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 equation, and I still
>>> do not
>>> >> know whether a budget equity amount is a correct approach.
>>> >>
>>> >> In 4.x series there is a planned *fix* which will scan budget amounts,
>>> >> use heuristics to determine the most likely sign-reversal approach
>>> used
>>> >> during budget creation, internally unreverse the amounts, and upgrade
>>> the
>>> >> datafile so that it cannot be damaged by 3.7 or earlier.
>>> >>
>>> >> Therefore 3.8 was the first release which could handle both old and
>>> fixed
>>> >> budget amounts. Unfortunately, the interpretation of budget signs
>>> was/is
>>> >> very difficult, which explained the switch to
>>> >> asset/liability/equity/income/expense totals, which are impervious to
>>> >> budget signs. Unfortunately users missed the "Remaining to Budget"
>>> facility.
>>> >>
>>> >> Therefore 3.9 was, during development, tested with
>>> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good
>>> enough"
>>> >> to fix to restore the remaining to budget total. Unfortunately the
>>> >> liability budget amount issue was tested incorrectly.
>>> >>
>>> >> For a week, the git-maint contained a candidate fix, discussed in
>>> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
>>> >> insufficient beta testing on the budgets for now. So, 3.10 will
>>> retain 3.9
>>> >> behaviour unless the fix is fully tested.
>>>

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[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
> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
>

Addendum this is not simply an arithmetic test; it *must also
confirm that the totals and signs are sensible for the purpose of
budgeting. Hence the difficulty of a one person coder to make it work. For
example, we can budget a liability account regularly until we have enough
deposit for a huge loan, or we can budget a liability account regularly for
the loan repayments. IIUC both approaches are "valid" but the signs will be
opposite. Other counter examples likely exist.

- budget.scm report (optionally other budget reports but these are lower
> priority) and especially difference column.
>
> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
>
>> 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 time frame do you have
>> and is there something in particular you’re looking to find. (other than
>> just loosely that the totals appear to work)
>>
>> Regards,
>> Adrien
>>
>> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
>> christopher@gmail.com> wrote:
>> >
>> > 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 <
>> christopher@gmail.com>
>> > wrote:
>> >
>> >> 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 equation, and I still
>> do not
>> >> know whether a budget equity amount is a correct approach.
>> >>
>> >> In 4.x series there is a planned *fix* which will scan budget amounts,
>> >> use heuristics to determine the most likely sign-reversal approach used
>> >> during budget creation, internally unreverse the amounts, and upgrade
>> the
>> >> datafile so that it cannot be damaged by 3.7 or earlier.
>> >>
>> >> Therefore 3.8 was the first release which could handle both old and
>> fixed
>> >> budget amounts. Unfortunately, the interpretation of budget signs
>> was/is
>> >> very difficult, which explained the switch to
>> >> asset/liability/equity/income/expense totals, which are impervious to
>> >> budget signs. Unfortunately users missed the "Remaining to Budget"
>> facility.
>> >>
>> >> Therefore 3.9 was, during development, tested with
>> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good
>> enough"
>> >> to fix to restore the remaining to budget total. Unfortunately the
>> >> liability budget amount issue was tested incorrectly.
>> >>
>> >> For a week, the git-maint contained a candidate fix, discussed in
>> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
>> >> insufficient beta testing on the budgets for now. So, 3.10 will retain
>> 3.9
>> >> behaviour unless the fix is fully tested.
>> >>
>> >> Conclusion: this is a call for beta testers, using the 2020-04-07
>> nightly
>> >> (the only one with the fix), to test both their datafiles and the
>> >> *4.x-featured* datafile attached in the bug report. Please *especially*
>> >> test the liability and equity totals, both with existing datafile and
>> >> featured datafile.
>> >>
>> >> Flame away. I will try to be available throughout the day for testing.
>> >> Win32 users have only 1 build to test, Linux users may also build from
>> >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour.
>> I'm
>> >> not sure how MacOS users can test.
>> >>
>> > ___
>> > gnucash-devel mailing list
>> > gnucash-devel@gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >
>>
>>
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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
- budget.scm report (optionally other budget reports but these are lower
priority) and especially difference column.

On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> 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 time frame do you have
> and is there something in particular you’re looking to find. (other than
> just loosely that the totals appear to work)
>
> Regards,
> Adrien
>
> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
> christopher@gmail.com> wrote:
> >
> > 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 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 equation, and I still do
> not
> >> know whether a budget equity amount is a correct approach.
> >>
> >> In 4.x series there is a planned *fix* which will scan budget amounts,
> >> use heuristics to determine the most likely sign-reversal approach used
> >> during budget creation, internally unreverse the amounts, and upgrade
> the
> >> datafile so that it cannot be damaged by 3.7 or earlier.
> >>
> >> Therefore 3.8 was the first release which could handle both old and
> fixed
> >> budget amounts. Unfortunately, the interpretation of budget signs was/is
> >> very difficult, which explained the switch to
> >> asset/liability/equity/income/expense totals, which are impervious to
> >> budget signs. Unfortunately users missed the "Remaining to Budget"
> facility.
> >>
> >> Therefore 3.9 was, during development, tested with
> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good
> enough"
> >> to fix to restore the remaining to budget total. Unfortunately the
> >> liability budget amount issue was tested incorrectly.
> >>
> >> For a week, the git-maint contained a candidate fix, discussed in
> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
> >> insufficient beta testing on the budgets for now. So, 3.10 will retain
> 3.9
> >> behaviour unless the fix is fully tested.
> >>
> >> Conclusion: this is a call for beta testers, using the 2020-04-07
> nightly
> >> (the only one with the fix), to test both their datafiles and the
> >> *4.x-featured* datafile attached in the bug report. Please *especially*
> >> test the liability and equity totals, both with existing datafile and
> >> featured datafile.
> >>
> >> Flame away. I will try to be available throughout the day for testing.
> >> Win32 users have only 1 build to test, Linux users may also build from
> >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm
> >> not sure how MacOS users can test.
> >>
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 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 equation, and I still do not
> know whether a budget equity amount is a correct approach.
>
> In 4.x series there is a planned *fix* which will scan budget amounts,
> use heuristics to determine the most likely sign-reversal approach used
> during budget creation, internally unreverse the amounts, and upgrade the
> datafile so that it cannot be damaged by 3.7 or earlier.
>
> Therefore 3.8 was the first release which could handle both old and fixed
> budget amounts. Unfortunately, the interpretation of budget signs was/is
> very difficult, which explained the switch to
> asset/liability/equity/income/expense totals, which are impervious to
> budget signs. Unfortunately users missed the "Remaining to Budget" facility.
>
> Therefore 3.9 was, during development, tested with
> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough"
> to fix to restore the remaining to budget total. Unfortunately the
> liability budget amount issue was tested incorrectly.
>
> For a week, the git-maint contained a candidate fix, discussed in
> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9
> behaviour unless the fix is fully tested.
>
> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly
> (the only one with the fix), to test both their datafiles and the
> *4.x-featured* datafile attached in the bug report. Please *especially*
> test the liability and equity totals, both with existing datafile and
> featured datafile.
>
> Flame away. I will try to be available throughout the day for testing.
> Win32 users have only 1 build to test, Linux users may also build from
> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm
> not sure how MacOS users can test.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Christopher Lam]

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 equation, and I still do not
know whether a budget equity amount is a correct approach.

In 4.x series there is a planned *fix* which will scan budget amounts, use
heuristics to determine the most likely sign-reversal approach used during
budget creation, internally unreverse the amounts, and upgrade the datafile
so that it cannot be damaged by 3.7 or earlier.

Therefore 3.8 was the first release which could handle both old and fixed
budget amounts. Unfortunately, the interpretation of budget signs was/is
very difficult, which explained the switch to
asset/liability/equity/income/expense totals, which are impervious to
budget signs. Unfortunately users missed the "Remaining to Budget" facility.

Therefore 3.9 was, during development, tested with
https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" to
fix to restore the remaining to budget total. Unfortunately the liability
budget amount issue was tested incorrectly.

For a week, the git-maint contained a candidate fix, discussed in
https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9
behaviour unless the fix is fully tested.

Conclusion: this is a call for beta testers, using the 2020-04-07 nightly
(the only one with the fix), to test both their datafiles and the
*4.x-featured* datafile attached in the bug report. Please *especially*
test the liability and equity totals, both with existing datafile and
featured datafile.

Flame away. I will try to be available throughout the day for testing.
Win32 users have only 1 build to test, Linux users may also build from
882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm
not sure how MacOS users can test.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Starting Balance in Reconciliation Window wrong

[Christopher Lam]

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 invalid
data (without a book property or a book feature) is highlighted exactly by
David Carlson's opinion: if old data was not consistently precise in
requiring accurate reconciliation statement dates, it could mean that
fixing reconciliation dates safely is practically impossible; I do not
think there is a safe one-time scrubbing mechanism (either silently as are
other scrubs in existence, or UI-driven) which is guaranteed to work well.
With a book property/feature approach, a natural progression of this "fix"
is that reconciled dates & balances *will* be stored and can a
data-integrity check be re-run anytime, thereby providing reconciled
balance assertions. But this will be reserved for a future time.

So, 3.10 is planned for this weekend.

On Fri, 10 Apr 2020 at 01:02, David Carlson 
wrote:

> Some users like me did a lot of mis-managed reconciling while importing old
> data into currently used accounts and just reconciling years of
> transactions as of the current month instead of trying to obsessively go
> back years and assign the transactions to years-old statements, especially
> when reconcile dates cannot be viewed in the UI.  While I doubt that we
> would want to correct those old transactions, if reconcile dates would
> somehow become visible sometime in the future, we might need to
> occasionally find and fix some transactions here and there, especially if
> they had been re-reconciled to the wrong month after an edit erroneously
> un-reconciled them.
>
> On Thu, Apr 9, 2020 at 7:30 PM David Cousens 
> wrote:
>
> > David T.
> >
> > Yes I did correct and eliminate the problem by editing the data file
> > directly and I also agree this is not really viable for the average
> user. I
> > only had one incorrectly entered date in one account and for users who
> have
> > many years of data the situation could be considerably more complex. I
> also
> > had external information about when I had performed past reconcilaitions
> so
> > my fix was a simple search and replace once I had verified that it was a
> > single reconciliation date and the splits which were incorrect agreed
> with
> > the date I suspected should have been entered.
> >
> > I made some suggestions in the DEV forum in response to Chris's options
> for
> > a way forward by making the feature optional which may allow the feature
> to
> > be retained but switched off by default in preexisting datafiles and only
> > switched on by default in new data files that may allow retention of the
> > feature with no disruption for user's with files which may have wrong
> past
> > reconciliation dates. It obviously depends on how easy the changes needed
> > to
> > implement that are.
> >
> > Another user has raised a separate issue which seems to be associated
> with
> > a
> > different startup of the reconciliation process automatically when using
> > AQbanking to import balances which may or may not be related. He has
> raised
> > a separate bug report and I have closed the one I raised as resolved.
> >
> > David Cousens
> >
> >
> >
> > -
> > David Cousens
> > --
> > Sent from:
> http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> > ___
> > gnucash-user mailing list
> > gnucash-u...@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
>
>
> --
> David Carlson
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

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
strict reconcile date balances".
Pros: This means the book can be read/written by any recent version. See
"Use split action for num" as a similar example.
Cons: The toggled property can be a confusing option for new users.

3. allow this change depending on a non-user-selectable book feature "Use
strict reconcile date balances".
Pros: This feature can be set by a menu item. It triggers one-time
verification of all reconciled dates, instructing users to
correct/re-reconcile previous reconciled-dates, and sets the book feature
if all dates seem correct.
Cons: This means the book can only be read by 3.10 onwards.

On Thu, 9 Apr 2020, 11:29 am Christopher Lam, 
wrote:

> Thank you David.
>
> Further work for tighter safeguards is planned in
> https://github.com/Gnucash/gnucash/pull/685 -- no scrubbing is currently
> on the table but a warning during reconciliation if future splits are
> detected.
>
> On Thu, 9 Apr 2020, 9:59 am David Cousens, 
> wrote:
>
>> I am now happy that there is no problem with the starting balance
>> calculation
>> in 3.9  and the problem was caused by a previously undetected finger
>> problem
>> on my part  and withdraw my previous qualms about retaining it for the
>> future.
>>
>> I still think it is excessive to restrict the reconciliation date entry in
>> any way but agree that a warning should be displayed if either a statment
>> date in advance of "today" is entered, perhaps with the option for the
>> user
>> to confirm that they either want to retain the advance date or reenter it
>> in
>> a popup dialog.
>>
>> Also agree with a warning if any reconciled transactions with reconcile
>> dates  in advance of today are detected in the file. I am less sure about
>> assigning them to an arbitrary past date however.
>>
>> If a procedure for correcting them is developed it might be helpful if it
>> could display data for transactiions with reconciled splits which have the
>> advance date. The information that I found most useful to determine when I
>> made the error were the transaction date posted and the transaction date
>> entered into GnuCash and the reconciliation date and the account name or
>> at
>> least the account guid to confirm that all the affected splits are to a
>> single account. This was particularlyuseful to me because i append an "_R"
>> to statement pdf files I have reconciled and the file modified time allows
>> me to determine the date I did a recociliation. In future I will append
>> "_Rmmdd" so i don't have to look up the modified times for the files
>> as
>> well.
>>
>> Bug797668 is now marked as resolved
>>
>>
>>
>> -
>> David Cousens
>> --
>> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

Thank you David.

Further work for tighter safeguards is planned in
https://github.com/Gnucash/gnucash/pull/685 -- no scrubbing is currently on
the table but a warning during reconciliation if future splits are detected.

On Thu, 9 Apr 2020, 9:59 am David Cousens,  wrote:

> I am now happy that there is no problem with the starting balance
> calculation
> in 3.9  and the problem was caused by a previously undetected finger
> problem
> on my part  and withdraw my previous qualms about retaining it for the
> future.
>
> I still think it is excessive to restrict the reconciliation date entry in
> any way but agree that a warning should be displayed if either a statment
> date in advance of "today" is entered, perhaps with the option for the user
> to confirm that they either want to retain the advance date or reenter it
> in
> a popup dialog.
>
> Also agree with a warning if any reconciled transactions with reconcile
> dates  in advance of today are detected in the file. I am less sure about
> assigning them to an arbitrary past date however.
>
> If a procedure for correcting them is developed it might be helpful if it
> could display data for transactiions with reconciled splits which have the
> advance date. The information that I found most useful to determine when I
> made the error were the transaction date posted and the transaction date
> entered into GnuCash and the reconciliation date and the account name or at
> least the account guid to confirm that all the affected splits are to a
> single account. This was particularlyuseful to me because i append an "_R"
> to statement pdf files I have reconciled and the file modified time allows
> me to determine the date I did a recociliation. In future I will append
> "_Rmmdd" so i don't have to look up the modified times for the files as
> well.
>
> Bug797668 is now marked as resolved
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] About 3.9 and reconciliation balances

[Christopher Lam]

Release 3.9 comes with a new method for calculating reconciliation starting
balances.

Previously, the account reconciled balance was considered the starting
balance. This includes any splits previously reconciled with an invalid
(e.g. future) reconciliation statement date.

>From 3.9 onwards, the starting balance is calculated by adding all account
splits whose *previous *reconciled date the *current* reconciliation date.
This means any past reconciliation with an invalid (ie future) reconciled
date would be ignored. The benefit is to allow re-reconciliation of a past
statement.

So, anyone with difficulties reconciling an account with 3.9 onwards should
check the account Reconciliation Report, Start Date = today, End Date =
31/12/ to seek these splits. To fix it manually, you can unreconcile
them and re-reconcile with any past date or today. Or modify the XML/SQL to
fix these dates.

To prevent future issues there are several safeguards being planned for
3.10:

1. any reconciliation must have a statement date of TODAY + 1MONTH. This
allows some leeway for users who wish to reconcile in advance, yet
disallows reconciliation too far ahead.

2. a datafile with splits with reconciled_date in the future *may *be
repaired; e.g. if reconciled_date > 1 month from today, then it is
evidently an error and can be changed to an arbitrary old date eg 1/1/1970.
This will allow them to be counted when calculating modern reconciled
balances.

I think 1 is acceptable. Any particular votes for 2?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Failed - import of QIF files from Quicken

[Christopher Lam]

Thank you for your rant.

Unfortunately we want all messages to be public.

FYI all developers are volunteers, and this duplicate-transaction bug will
be fixed for 3.10.

On Fri, 3 Apr 2020 at 20:31, Tom Hatzigeorgiou  wrote:

> Sorry Jim but I do not agree
>
> For me the problem is with GNU and not with Quicken.
>
> Here is my rationale.
>
> The problem that (at least) I have with the importer started after version
> 3.1.
>
> Every time I have to import my data I downgrade to GNU 3.1 import the data
> and then re-upgrade to the latest one and use the 3.1 imported file.
>
> Did it today and worked like a charm. NO DUPLICATE ENTRIES.
>
>
>
> I think that the distribution needed to modernize the importer, but
> whoever did it, he screw it up. He did not had a good enough test sample
> data.
>
> I don’t mind because as I said I have a solution to my problem.
>
> *The problem is with so many who want to adapt GNUCASH and cant because
> they can’t import their data.*
>
>
>
> I would say, if the program is modular, please substitute into 3.9 the
> importer of 3.1, until someone fixes this problem with the current one.
>
> Or remove the 3.9 importer and create a standalone importer using the 3.1
> module, so people like me don’t have to jump through hoops to import their
> data.
>
> The only part of the program that I don’t care how modern it is, is the
> importer, since I would use it only once. BUT it has to work right.
>
>
>
> Thank you for your emails.
>
> Tom
>
>
>
>
>
> *From: *James Peterson 
> *Sent: *Friday, April 3, 2020 12:44 PM
> *To: *Tom Hatzigeorgiou ; Christopher Lam
> 
> *Subject: *Re: [GNC-dev] [GNC] Failed - import of QIF files from Quicken
>
>
>
> Christopher indicated to me that what you report would be
> the case.
>
> The problem is double entry bookkeeping.  Quicken does it
> by making a debit in one account and a credit in another
> account.  Both of these entries are in the QIF file.
> Gnucash has to then find these two entries and combine
> them back into one.  If it fails to recognize they are
> the same transaction, it will then fill in the other end
> of the "missing" transaction.  So a transfer of $5000 from
> one account to another may show up in GNC as two deposits
> of $5000 in the receiving account:  one from Quicken and
> another one from GNC doing double entry, but having missed
> that Quicken already did that.
>
> There is a lot of code in GNC to recognize the double entries,
> but apparently only in the case of data from separate QIF files.
> So if you have one big QIF file, then you will get duplicate
> entries.  But if you have each account in its own QIF file,
> then the inter-account actions will be (should be) properly
> recognized and things should be okay.
>
> But I have, like, 100 accounts over 30 years, so that would
> be a real pain for me.  All those QIF files, generated by
> hand, even just once for migration purposes.  Maybe it would
> be easier for you.
>
> And it generally just doesn't like transactions where both
> the source and destination are the same account (why would
> you do that?)  which I have 133 or so of.
>
> That's what I understand, but I could be wrong.
>
> jim
>
>
>
>
>
> On Fri, 2020-04-03 at 15:44 +, Tom Hatzigeorgiou wrote:
> > Hi guys
> > If you remember we were talking about the failure on the import of the
> QIF
> > file.
> > I’m happy to report that the error is fixed with version 3.9. I can now
> > import my whole QIF data file without a failure on the import process. I
> > would like to believe that I had some input into this fix.
> >
> > The problem now is that when the file is imported (successfully) the
> data in
> > the account are NOT correct.
> > At a first glance I see a lot of transfers that are duplicated.
> > I hope that is not a huge issue and that you will fix it soon at a later
> > release.
> >
> > Thank you.
> >
> >
> >
> >
> > From: Tom Hatzigeorgiou
> > Sent: Saturday, February 29, 2020 7:38 PM
> > To: Christopher Lam; crazylyle
> > Subject: Re: [GNC-dev] [GNC] Failed - import of QIF files from Quicken
> >
> > thank you Chris
> > If I could understand what you said I could apply it on my whole file and
> > test if it fixed the issue on the whole file.
> > Any way this can be done as a preprocess of the latest importer
> > That could fix the problem for everyone.
> >
> > Thanks.
> >
> >
> >
> > From: Christopher Lam 
> > Sent: Saturday, February 29, 2020 9:52 AM
> > To: Tom Hatzigeorgiou ; cra

Re: [GNC-dev] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Christopher Lam]

All/cleared/reconciled Balance as of anydate has always been available, but
is not hooked up to the SX editor nor the mortgage druid AFAIK

On Thu, 2 Apr 2020 at 05:17, David Reiser  wrote:

> I’m glad it works. The next question is could this calculation be the
> basis for calculating balance-on-a-date for the purpose of calculating
> interest on loan payments that include irregular, extra principal payments?
> I’m just about done paying off loans, but I pay ahead on my mortgage, and
> my credit union calculates interest on days since last payment (which
> changes in at least 11 out of 12 months anyway).
> --
> Dave Reiser
> dbrei...@icloud.com
>
>
>
>
>
> On Apr 2, 2020, at 1:10 AM, Christopher Lam 
> wrote:
>
> Thank you for helping troubleshoot this issue.
>
> The dilemma is whether to keep this change which exposes invalid
> reconciliation statement dates, or revert to previous behaviour. The only
> UI available to fix these dates is to unreconcile the old splits and
> rereconcile old statements (or use latest statement).
>
> On Thu, 2 Apr 2020 at 05:06, David Reiser  wrote:
>
>> Correct. I edited the raw .xml file. Seems to be fixed.
>> --
>> Dave Reiser
>> dbrei...@icloud.com
>>
>>
>>
>>
>>
>> On Apr 2, 2020, at 1:04 AM, Christopher Lam 
>> wrote:
>>
>> My suspicion is that your reconciliation for June 2006 used a bogus date.
>> Try expand the date filter to End-Date = 31/12/.
>>
>> If I'm right then you could unreconcile the June 2006 splits and
>> re-reconcile the 30 June 2006 statement?
>>
>> On Thu, 2 Apr 2020 at 01:49, David Reiser  wrote:
>>
>>> The reconcile report is missing all the transactions from June 2006
>>> (06/06…).
>>> --
>>> Dave Reiser
>>> dbrei...@icloud.com
>>>
>>>
>>>
>>>
>>>
>>> On Apr 1, 2020, at 11:47 AM, Christopher Lam 
>>> wrote:
>>>
>>> Would you mind trying the Reconciliation Report. We're confirming that
>>> *all* reconciled_dates column are reasonable. Please feel free to send the
>>> resulting report privately.
>>>
>>> Account = Savings
>>> Start Date = 1/1/1970
>>> End Date = today
>>>
>>>
>>> On Wed, 1 Apr 2020 at 15:23, Christopher Lam 
>>> wrote:
>>>
>>>> (snipped screenshot showing a very regular savings account with monthly
>>>> reconciled interest splits until 31.1.2020 and monthly cleared interest
>>>> splits afterwards).
>>>>
>>>> Apologies I cannot understand how/why the starting balance calculator
>>>> would not show the appropriate amount. I assume you're not including
>>>> subaccounts in your reconciliation. The 3.9 starting balance is calculated
>>>> at
>>>> https://github.com/Gnucash/gnucash/blob/90d3e6c6721ffb3f7e53adfd8bbd2f1b6933cb3d/libgnucash/engine/Account.cpp#L3402
>>>> --
>>>>
>>>> Scan all (savings) account splits, if split's *reconciled_status* is
>>>> 'y' and the *reconciled_date* <= *statement_date* then accumulate its
>>>> value. Note the *reconciled_date* will be the statement_date for
>>>> previous months' reconciliations, therefore all splits from previous
>>>> reconciliations *should* be counted without fail. If you could create
>>>> a dev environment I could offer a repository with appropriate logging.
>>>> Unfortunately I do not know how to package a .dmg.
>>>>
>>>> Alternatively if you can install a custom report I can create a .scm
>>>> file to log a similar reconciled_balance accumulator.
>>>>
>>>> C
>>>>
>>>>> On Apr 1, 2020, at 10:40 AM, Christopher Lam <
>>>>> christopher@gmail.com> wrote:
>>>>>
>>>>> Specifically interested in the register screenshot from 1-Jan-2020
>>>>> onwards -- wish to verify balances/reconcile-status etc. Thank you. 
>>>>> Regards
>>>>>>
>>>>>> Care to share a screenshot of your savings account register
>>>>>> privately? Earlier splits are not needed. Thanks.
>>>>>>
>>>>>> On Wed, 1 Apr 2020, 10:06 pm David Reiser, 
>>>>>> wrote:
>>>>>>
>>>>>>> I have no problem with (A), except maybe if you’re using the gnucash
>>>>>>> posting date. A reconciliation resolves transactions based on the bank’s
>>

Re: [GNC-dev] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Christopher Lam]

Thank you for helping troubleshoot this issue.

The dilemma is whether to keep this change which exposes invalid
reconciliation statement dates, or revert to previous behaviour. The only
UI available to fix these dates is to unreconcile the old splits and
rereconcile old statements (or use latest statement).

On Thu, 2 Apr 2020 at 05:06, David Reiser  wrote:

> Correct. I edited the raw .xml file. Seems to be fixed.
> --
> Dave Reiser
> dbrei...@icloud.com
>
>
>
>
>
> On Apr 2, 2020, at 1:04 AM, Christopher Lam 
> wrote:
>
> My suspicion is that your reconciliation for June 2006 used a bogus date.
> Try expand the date filter to End-Date = 31/12/.
>
> If I'm right then you could unreconcile the June 2006 splits and
> re-reconcile the 30 June 2006 statement?
>
> On Thu, 2 Apr 2020 at 01:49, David Reiser  wrote:
>
>> The reconcile report is missing all the transactions from June 2006
>> (06/06…).
>> --
>> Dave Reiser
>> dbrei...@icloud.com
>>
>>
>>
>>
>>
>> On Apr 1, 2020, at 11:47 AM, Christopher Lam 
>> wrote:
>>
>> Would you mind trying the Reconciliation Report. We're confirming that
>> *all* reconciled_dates column are reasonable. Please feel free to send the
>> resulting report privately.
>>
>> Account = Savings
>> Start Date = 1/1/1970
>> End Date = today
>>
>>
>> On Wed, 1 Apr 2020 at 15:23, Christopher Lam 
>> wrote:
>>
>>> (snipped screenshot showing a very regular savings account with monthly
>>> reconciled interest splits until 31.1.2020 and monthly cleared interest
>>> splits afterwards).
>>>
>>> Apologies I cannot understand how/why the starting balance calculator
>>> would not show the appropriate amount. I assume you're not including
>>> subaccounts in your reconciliation. The 3.9 starting balance is calculated
>>> at
>>> https://github.com/Gnucash/gnucash/blob/90d3e6c6721ffb3f7e53adfd8bbd2f1b6933cb3d/libgnucash/engine/Account.cpp#L3402
>>> --
>>>
>>> Scan all (savings) account splits, if split's *reconciled_status* is
>>> 'y' and the *reconciled_date* <= *statement_date* then accumulate its
>>> value. Note the *reconciled_date* will be the statement_date for
>>> previous months' reconciliations, therefore all splits from previous
>>> reconciliations *should* be counted without fail. If you could create a
>>> dev environment I could offer a repository with appropriate logging.
>>> Unfortunately I do not know how to package a .dmg.
>>>
>>> Alternatively if you can install a custom report I can create a .scm
>>> file to log a similar reconciled_balance accumulator.
>>>
>>> C
>>>
>>>> On Apr 1, 2020, at 10:40 AM, Christopher Lam 
>>>> wrote:
>>>>
>>>> Specifically interested in the register screenshot from 1-Jan-2020
>>>> onwards -- wish to verify balances/reconcile-status etc. Thank you. Regards
>>>>>
>>>>> Care to share a screenshot of your savings account register privately?
>>>>> Earlier splits are not needed. Thanks.
>>>>>
>>>>> On Wed, 1 Apr 2020, 10:06 pm David Reiser, 
>>>>> wrote:
>>>>>
>>>>>> I have no problem with (A), except maybe if you’re using the gnucash
>>>>>> posting date. A reconciliation resolves transactions based on the bank’s
>>>>>> posting date, not gnucash’s. If I don’t enter March 31, 2020 interest 
>>>>>> until
>>>>>> April 1, I’m still going to enter it in my account as having occurred on
>>>>>> 3/31. But even that distinction can’t be causing what I’m seeing.
>>>>>>
>>>>>> In my simplest case, my savings account was last reconciled based on
>>>>>> the interest paid 1/31/2020. On 2/29 I received $0.96 in interest and on
>>>>>> 3/31 I received $1.03 in interest. There were no other transactions 
>>>>>> during
>>>>>> that time. I have no idea when I entered the February interest, but I did
>>>>>> enter the March interest on 3/31/2020 (at least it was still 3/31 on the
>>>>>> U.S. east coast).
>>>>>>
>>>>>> When I click Reconcile, in the Reconcile Information dialog, I get:
>>>>>> Statement date 02/29/2020
>>>>>> Starting Balance $3024.39 (this amount was reconciled in gnucash 3.7)
>>>>>> ending Balanc

Re: [GNC-dev] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Christopher Lam]

My suspicion is that your reconciliation for June 2006 used a bogus date.
Try expand the date filter to End-Date = 31/12/.

If I'm right then you could unreconcile the June 2006 splits and
re-reconcile the 30 June 2006 statement?

On Thu, 2 Apr 2020 at 01:49, David Reiser  wrote:

> The reconcile report is missing all the transactions from June 2006
> (06/06…).
> --
> Dave Reiser
> dbrei...@icloud.com
>
>
>
>
>
> On Apr 1, 2020, at 11:47 AM, Christopher Lam 
> wrote:
>
> Would you mind trying the Reconciliation Report. We're confirming that
> *all* reconciled_dates column are reasonable. Please feel free to send the
> resulting report privately.
>
> Account = Savings
> Start Date = 1/1/1970
> End Date = today
>
>
> On Wed, 1 Apr 2020 at 15:23, Christopher Lam 
> wrote:
>
>> (snipped screenshot showing a very regular savings account with monthly
>> reconciled interest splits until 31.1.2020 and monthly cleared interest
>> splits afterwards).
>>
>> Apologies I cannot understand how/why the starting balance calculator
>> would not show the appropriate amount. I assume you're not including
>> subaccounts in your reconciliation. The 3.9 starting balance is calculated
>> at
>> https://github.com/Gnucash/gnucash/blob/90d3e6c6721ffb3f7e53adfd8bbd2f1b6933cb3d/libgnucash/engine/Account.cpp#L3402
>> --
>>
>> Scan all (savings) account splits, if split's *reconciled_status* is 'y'
>> and the *reconciled_date* <= *statement_date* then accumulate its value.
>> Note the *reconciled_date* will be the statement_date for previous
>> months' reconciliations, therefore all splits from previous reconciliations
>> *should* be counted without fail. If you could create a dev environment
>> I could offer a repository with appropriate logging. Unfortunately I do not
>> know how to package a .dmg.
>>
>> Alternatively if you can install a custom report I can create a .scm file
>> to log a similar reconciled_balance accumulator.
>>
>> C
>>
>>> On Apr 1, 2020, at 10:40 AM, Christopher Lam 
>>> wrote:
>>>
>>> Specifically interested in the register screenshot from 1-Jan-2020
>>> onwards -- wish to verify balances/reconcile-status etc. Thank you. Regards
>>>>
>>>> Care to share a screenshot of your savings account register privately?
>>>> Earlier splits are not needed. Thanks.
>>>>
>>>> On Wed, 1 Apr 2020, 10:06 pm David Reiser,  wrote:
>>>>
>>>>> I have no problem with (A), except maybe if you’re using the gnucash
>>>>> posting date. A reconciliation resolves transactions based on the bank’s
>>>>> posting date, not gnucash’s. If I don’t enter March 31, 2020 interest 
>>>>> until
>>>>> April 1, I’m still going to enter it in my account as having occurred on
>>>>> 3/31. But even that distinction can’t be causing what I’m seeing.
>>>>>
>>>>> In my simplest case, my savings account was last reconciled based on
>>>>> the interest paid 1/31/2020. On 2/29 I received $0.96 in interest and on
>>>>> 3/31 I received $1.03 in interest. There were no other transactions during
>>>>> that time. I have no idea when I entered the February interest, but I did
>>>>> enter the March interest on 3/31/2020 (at least it was still 3/31 on the
>>>>> U.S. east coast).
>>>>>
>>>>> When I click Reconcile, in the Reconcile Information dialog, I get:
>>>>> Statement date 02/29/2020
>>>>> Starting Balance $3024.39 (this amount was reconciled in gnucash 3.7)
>>>>> ending Balance $3025.36  (reasonable, since 3024.39 + 0.96 = 3025.35)
>>>>>
>>>>> Now if I click OK to get to the transaction check-off dialog, I get:
>>>>>
>>>>> Starting balance: 375.15  (What???)
>>>>> Ending Balance: 3025.36 (well, it remembered what I entered)
>>>>> Reconciled balance: 376.11 (well, it is 375.15 + 0.96 …)
>>>>>
>>>>> Difference: 2649.24 (the math is locally consistent, but the starting
>>>>> balance doesn’t represent anything in my register or what gnucash showed 
>>>>> me
>>>>> on the prior screen)
>>>>>
>>>>> On Apr 1, 2020, at 1:19 AM, Christopher Lam 
>>>>> wrote:
>>>>>
>>>>> This is due to https://bugs.gnucash.org/show_bug.cgi?id=797640
>>>>>
>>>>> This change modifies the recon

Re: [GNC-dev] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Christopher Lam]

Would you mind trying the Reconciliation Report. We're confirming that
*all* reconciled_dates column are reasonable. Please feel free to send the
resulting report privately.

Account = Savings
Start Date = 1/1/1970
End Date = today


On Wed, 1 Apr 2020 at 15:23, Christopher Lam 
wrote:

> (snipped screenshot showing a very regular savings account with monthly
> reconciled interest splits until 31.1.2020 and monthly cleared interest
> splits afterwards).
>
> Apologies I cannot understand how/why the starting balance calculator
> would not show the appropriate amount. I assume you're not including
> subaccounts in your reconciliation. The 3.9 starting balance is calculated
> at
> https://github.com/Gnucash/gnucash/blob/90d3e6c6721ffb3f7e53adfd8bbd2f1b6933cb3d/libgnucash/engine/Account.cpp#L3402
> --
>
> Scan all (savings) account splits, if split's *reconciled_status* is 'y'
> and the *reconciled_date* <= *statement_date* then accumulate its value.
> Note the *reconciled_date* will be the statement_date for previous
> months' reconciliations, therefore all splits from previous reconciliations
> *should* be counted without fail. If you could create a dev environment I
> could offer a repository with appropriate logging. Unfortunately I do not
> know how to package a .dmg.
>
> Alternatively if you can install a custom report I can create a .scm file
> to log a similar reconciled_balance accumulator.
>
> C
>
>> On Apr 1, 2020, at 10:40 AM, Christopher Lam 
>> wrote:
>>
>> Specifically interested in the register screenshot from 1-Jan-2020
>> onwards -- wish to verify balances/reconcile-status etc. Thank you. Regards
>>>
>>> Care to share a screenshot of your savings account register privately?
>>> Earlier splits are not needed. Thanks.
>>>
>>> On Wed, 1 Apr 2020, 10:06 pm David Reiser,  wrote:
>>>
>>>> I have no problem with (A), except maybe if you’re using the gnucash
>>>> posting date. A reconciliation resolves transactions based on the bank’s
>>>> posting date, not gnucash’s. If I don’t enter March 31, 2020 interest until
>>>> April 1, I’m still going to enter it in my account as having occurred on
>>>> 3/31. But even that distinction can’t be causing what I’m seeing.
>>>>
>>>> In my simplest case, my savings account was last reconciled based on
>>>> the interest paid 1/31/2020. On 2/29 I received $0.96 in interest and on
>>>> 3/31 I received $1.03 in interest. There were no other transactions during
>>>> that time. I have no idea when I entered the February interest, but I did
>>>> enter the March interest on 3/31/2020 (at least it was still 3/31 on the
>>>> U.S. east coast).
>>>>
>>>> When I click Reconcile, in the Reconcile Information dialog, I get:
>>>> Statement date 02/29/2020
>>>> Starting Balance $3024.39 (this amount was reconciled in gnucash 3.7)
>>>> ending Balance $3025.36  (reasonable, since 3024.39 + 0.96 = 3025.35)
>>>>
>>>> Now if I click OK to get to the transaction check-off dialog, I get:
>>>>
>>>> Starting balance: 375.15  (What???)
>>>> Ending Balance: 3025.36 (well, it remembered what I entered)
>>>> Reconciled balance: 376.11 (well, it is 375.15 + 0.96 …)
>>>>
>>>> Difference: 2649.24 (the math is locally consistent, but the starting
>>>> balance doesn’t represent anything in my register or what gnucash showed me
>>>> on the prior screen)
>>>>
>>>> On Apr 1, 2020, at 1:19 AM, Christopher Lam 
>>>> wrote:
>>>>
>>>> This is due to https://bugs.gnucash.org/show_bug.cgi?id=797640
>>>>
>>>> This change modifies the reconciliation starting balance calculator
>>>> from Account->reconciled_balance to account->reconciled_balance on
>>>> statement date.
>>>>
>>>> The reasoning for this change is with the observation:
>>>>
>>>> (A) if reconciliation is performed from a statement dated 31/01/2019,
>>>> the starting balance calculator should ignore transactions posted later
>>>> than 31/01/2019.
>>>>
>>>> (B) subsequent work https://github.com/Gnucash/gnucash/pull/667 aims
>>>> to store past reconciliation ending balances and statement date. As a
>>>> result we can re-reconcile any past statement.
>>>>
>>>> (C) subsequent work will allow a sanity-check type report (illustrated
>>>> in above PR)  which will compare account reco

Re: [GNC-dev] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Christopher Lam]

(snipped screenshot showing a very regular savings account with monthly
reconciled interest splits until 31.1.2020 and monthly cleared interest
splits afterwards).

Apologies I cannot understand how/why the starting balance calculator would
not show the appropriate amount. I assume you're not including subaccounts
in your reconciliation. The 3.9 starting balance is calculated at
https://github.com/Gnucash/gnucash/blob/90d3e6c6721ffb3f7e53adfd8bbd2f1b6933cb3d/libgnucash/engine/Account.cpp#L3402
--

Scan all (savings) account splits, if split's *reconciled_status* is 'y'
and the *reconciled_date* <= *statement_date* then accumulate its value.
Note the *reconciled_date* will be the statement_date for previous months'
reconciliations, therefore all splits from previous reconciliations *should*
be counted without fail. If you could create a dev environment I could
offer a repository with appropriate logging. Unfortunately I do not know
how to package a .dmg.

Alternatively if you can install a custom report I can create a .scm file
to log a similar reconciled_balance accumulator.

C

> On Apr 1, 2020, at 10:40 AM, Christopher Lam 
> wrote:
>
> Specifically interested in the register screenshot from 1-Jan-2020 onwards
> -- wish to verify balances/reconcile-status etc. Thank you. Regards
>>
>> Care to share a screenshot of your savings account register privately?
>> Earlier splits are not needed. Thanks.
>>
>> On Wed, 1 Apr 2020, 10:06 pm David Reiser,  wrote:
>>
>>> I have no problem with (A), except maybe if you’re using the gnucash
>>> posting date. A reconciliation resolves transactions based on the bank’s
>>> posting date, not gnucash’s. If I don’t enter March 31, 2020 interest until
>>> April 1, I’m still going to enter it in my account as having occurred on
>>> 3/31. But even that distinction can’t be causing what I’m seeing.
>>>
>>> In my simplest case, my savings account was last reconciled based on the
>>> interest paid 1/31/2020. On 2/29 I received $0.96 in interest and on 3/31 I
>>> received $1.03 in interest. There were no other transactions during that
>>> time. I have no idea when I entered the February interest, but I did enter
>>> the March interest on 3/31/2020 (at least it was still 3/31 on the U.S.
>>> east coast).
>>>
>>> When I click Reconcile, in the Reconcile Information dialog, I get:
>>> Statement date 02/29/2020
>>> Starting Balance $3024.39 (this amount was reconciled in gnucash 3.7)
>>> ending Balance $3025.36  (reasonable, since 3024.39 + 0.96 = 3025.35)
>>>
>>> Now if I click OK to get to the transaction check-off dialog, I get:
>>>
>>> Starting balance: 375.15  (What???)
>>> Ending Balance: 3025.36 (well, it remembered what I entered)
>>> Reconciled balance: 376.11 (well, it is 375.15 + 0.96 …)
>>>
>>> Difference: 2649.24 (the math is locally consistent, but the starting
>>> balance doesn’t represent anything in my register or what gnucash showed me
>>> on the prior screen)
>>>
>>> On Apr 1, 2020, at 1:19 AM, Christopher Lam 
>>> wrote:
>>>
>>> This is due to https://bugs.gnucash.org/show_bug.cgi?id=797640
>>>
>>> This change modifies the reconciliation starting balance calculator from
>>> Account->reconciled_balance to account->reconciled_balance on statement
>>> date.
>>>
>>> The reasoning for this change is with the observation:
>>>
>>> (A) if reconciliation is performed from a statement dated 31/01/2019,
>>> the starting balance calculator should ignore transactions posted later
>>> than 31/01/2019.
>>>
>>> (B) subsequent work https://github.com/Gnucash/gnucash/pull/667 aims to
>>> store past reconciliation ending balances and statement date. As a result
>>> we can re-reconcile any past statement.
>>>
>>> (C) subsequent work will allow a sanity-check type report (illustrated
>>> in above PR)  which will compare account reconciled balances at previous
>>> statement dates, and highlight any discrepancy.
>>>
>>> There have been previous feature requests to store and retrieve
>>> reconciled balances and reconciliation dates, and I believe it's possible
>>> and reasonable.
>>>
>>> Having explained the rationale, the reasoning (A) may be incorrect --
>>> please file in bug 797640 how/why starting_balance should include
>>> transactions posted after statement date. If reasoning (A) is invalid then
>>> we will need to revert the change, which means (B) and (C) above c

Re: [GNC-dev] Advice on what to look at next

[Christopher Lam]

I think: the transition 3.x to 4.x is roughly:
- new features incompatible to current code go into 4.x
- 3.x can potentially understand/read 4.x datafiles
- unused code in 3.x can get marked deprecated
- bug fixes and code cleanup in 3.x
- 3.x is merged into 4.x periodically so that 4.x receive bugfixes and code
cleanup
- deprecated code in 3.x can be removed in 4.x

Result: any datafile saved in 3.x should be readable by 4.x, but not
viceversa.

On Wed, 25 Mar 2020 at 04:30, jean  wrote:

> I have a possibly silly question. If the migration to 4.0 is somewhat
> near, what point is there in cleaning up the code in 3.x or removing
> hacks etc or even adding new features?
> Am I missing something?
> Jean
>
> On 3/23/20 5:55 PM, Chris Graves wrote:
> > For all you devs, it’s understood(or it should be) that what you do for
> this project is a labor of love.  Take your time, relax and just enjoy the
> fixes/enhancements that you bring to this project.  Who cares if a deadline
> needs to slip, just have fun!!!
> >
> > Thank you devs!!!
> > Chris
> >
> >> On Mar 23, 2020, at 5:22 PM, John Ralls  wrote:
> >>
> >> It's up in the air. The major sticking point is that I'm working on a
> major rewrite of the options system from an ugly mixture of C and Scheme to
> C++. I'd hoped to have it far enough along by now to start test releases,
> but it's not. The back end is mostly done and I'm 3/4 through with the GUI.
> After that is making sure that the Scheme API is compatible. (It's the
> c++options branch in my GitHub repo if you want to have a look. I haven't
> committed the GUI stuff yet, it doesn't build.) We'll have to discuss
> whether to proceed to user testing without it or slip the 4.0 release when
> Geert gets back from travel.
> >>
> >> Regards,
> >> John Ralls
> >>
> >>
> >>> On Mar 23, 2020, at 2:17 PM, Jean Laroche  wrote:
> >>>
> >>> How far along are you on 4.0? Is the planned 28 June 2020 release
> reasonable?
> >>> J.
> >>>
> >>> On 3/23/20 2:12 PM, Christopher Lam wrote:
> >>>> For a /very/ high level overview, see the design goals at
> https://wiki.gnucash.org/wiki/Release_Schedule
> >>>> Or, write tests and refactor the existing hacks.
> >>>> Or, feel free to squash bugs at leisure!
> >>>> On Mon, 23 Mar 2020 at 17:16, jeanl  rip...@gmail.com>> wrote:
> >>>>Devs,
> >>>>Can you point me to something you think needs to be looked at
> sooner
> >>>>rather
> >>>>than later in the gnucash code? I find that bugzilla does not give
> a
> >>>>good
> >>>>image of bug priority, but I'm sure you guys have a good idea of
> >>>>what needs
> >>>>to be fixed next. I wouldn't mind helping with that.
> >>>>Thanks,
> >>>>Jean
> >>>>--
> >>>>Sent from:
> >>>>http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> >>>>___
> >>>>gnucash-devel mailing list
> >>>>gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> >>>>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>> ___
> >>> gnucash-devel mailing list
> >>> gnucash-devel@gnucash.org
> >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Dipping my toes into Scheme

[Christopher Lam]

This may indicate a Mac .app issue -- maybe it doesn't like being modified.
For that matter it may be much safer to play on a Linux VM and downloading
the sources instead.
Alternatively try the config-user.scm method on
https://wiki.gnucash.org/wiki/Custom_Reports

On Mon, 23 Mar 2020 at 22:13, Michael Hendry 
wrote:

> > On 23 Mar 2020, at 12:48, Christopher Lam 
> wrote:
> >
> > This is more suitable for devel.
> >
> > On Mon, 23 Mar 2020 at 11:29, Michael Hendry 
> wrote:
> > Rather than dive into Scheme programming with a completely new report,
> I’d like to try editing an existing report to provide a little
> customisation.
> > I’m looking at the experimental report balsheet-pnl.scm by Christopher
> Lam, which I found here on my Mac…
> >
> > Not the easiest report to start with.
> >
> > In other programming environments I would simply save the edited file
> and run it, but I can see a few pitfalls!
> > Line 28 reads:
> > (define-module (gnucash report standard-reports balsheet-pnl))
> > which should presumably be changed, e.g. to:
> > (define-module (gnucash report standard-reports MH_balsheet-pnl))
> >
> > Correct. The define-module name must match the file path; this is a
> requirement in the standard-reports folder. Can't remember where exactly
> this is enforced.
> >
> > After that, I think it should be plain sailing until line 1340:
> > (define balsheet-reportname (_ "Balance Sheet (Multicolumn)"))
> > (define pnl-reportname (_ "Income Statement (Multicolumn)"))
> >
> > (gnc:define-report
> >  'version 1
> >  'name balsheet-reportname
> >  'report-guid "065d5d5a77ba11e8b31e83ada73c5eea"
> >  'menu-path (list gnc:menuname-experimental)
> >  'options-generator (lambda () (multicol-report-options-generator
> 'balsheet))
> >  'renderer (lambda (rpt) (multicol-report-renderer rpt 'balsheet)))
> >
> > (gnc:define-report
> >  'version 1
> >  'name pnl-reportname
> >  'report-guid "0e94fd0277ba11e8825d43e27232c9d4"
> >  'menu-path (list gnc:menuname-experimental)
> >  'options-generator (lambda () (multicol-report-options-generator 'pnl))
> >  'renderer (lambda (rpt) (multicol-report-renderer rpt 'pnl)))
> >
> > I expect there would be scope for confusion if I didn’t change lines
> 1340-1 - say prefixing “MH_” to the definitions, but I’m not sure about the
> options-generator and renderer lines.
> >
> > No. these lines define the options-generator to be a procedure with no
> arguments i.e. lambda () that calls (multicol-report-options-generator
> 'pnl). The 'pnl is used to direct the multicol-report-options-generator to
> provide options suitable for profit-n-loss aka 'pnl. See the definition of
> multicol-report-options-generator and locate where 'pnl is tested.
> >
> > uuidgen on my Mac issues 36-character uuids, with hyphens and uppercase,
> like this:
> > 47170C69-F87E-4A3B-9A97-8B97F56F5DFD
> > Would I need to edit them to give 32-character lowercase uuids, lacking
> hyphens?
> >
> > Actually any unique string of any length will do.
> >
> > Obviously, I have to take responsibility for my own programming
> experiments (and errors), but I’d appreciate a quick steer from someone
> with Scheme experience. Regards,
> > Michael
> >
> > Good luck!
>
> Thanks for your prompt response, Christopher.
>
> I was naive enough to think that all I had to do was create a duplicate
> report file in the same directory as above, rename it, then run GnuCash and
> see what happened.
>
> Unfortunately (i.e. predictably) what happened was the GC splash screen
> came up for a few seconds, then disappeared without bringing up the Gnucash
> UI.
>
> Running from the command line brought up an error message about
> compilation, but running with compilation switched off didn’t help.
>
> I’ve since deleted the new file, but still can’t get Gnucash to run - not
> even a newly downloaded and installed copy of version 3.8.
>
> I’ve clearly broken something fundamental, but having spent much of today
> searching for the damage, I’ve failed.
>
> I’d really appreciate a steer in the right direction, but I think I may
> have to uninstall GnuCash and start again.
>
> Michael
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Advice on what to look at next

[Christopher Lam]

For a *very* high level overview, see the design goals at
https://wiki.gnucash.org/wiki/Release_Schedule
Or, write tests and refactor the existing hacks.
Or, feel free to squash bugs at leisure!

On Mon, 23 Mar 2020 at 17:16, jeanl  wrote:

> Devs,
> Can you point me to something you think needs to be looked at sooner rather
> than later in the gnucash code? I find that bugzilla does not give a good
> image of bug priority, but I'm sure you guys have a good idea of what needs
> to be fixed next. I wouldn't mind helping with that.
> Thanks,
> Jean
>
>
>
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] Dipping my toes into Scheme

[Christopher Lam]

This is more suitable for devel.

On Mon, 23 Mar 2020 at 11:29, Michael Hendry 
wrote:

> Rather than dive into Scheme programming with a completely new report, I’d
> like to try editing an existing report to provide a little customisation.
> I’m looking at the experimental report balsheet-pnl.scm by Christopher
> Lam, which I found here on my Mac…
>

Not the easiest report to start with.


> In other programming environments I would simply save the edited file and
> run it, but I can see a few pitfalls!
> Line 28 reads:
> (define-module (gnucash report standard-reports balsheet-pnl))
> which should presumably be changed, e.g. to:
> (define-module (gnucash report standard-reports MH_balsheet-pnl))
>

Correct. The define-module name must match the file path; this is a
requirement in the standard-reports folder. Can't remember where exactly
this is enforced.

After that, I think it should be plain sailing until line 1340:
> (define balsheet-reportname (_ "Balance Sheet (Multicolumn)"))
> (define pnl-reportname (_ "Income Statement (Multicolumn)"))
>
> (gnc:define-report
>  'version 1
>  'name balsheet-reportname
>  'report-guid "065d5d5a77ba11e8b31e83ada73c5eea"
>  'menu-path (list gnc:menuname-experimental)
>  'options-generator (lambda () (multicol-report-options-generator
> 'balsheet))
>  'renderer (lambda (rpt) (multicol-report-renderer rpt 'balsheet)))
>
> (gnc:define-report
>  'version 1
>  'name pnl-reportname
>  'report-guid "0e94fd0277ba11e8825d43e27232c9d4"
>  'menu-path (list gnc:menuname-experimental)
>  'options-generator (lambda () (multicol-report-options-generator 'pnl))
>  'renderer (lambda (rpt) (multicol-report-renderer rpt 'pnl)))
>
> I expect there would be scope for confusion if I didn’t change lines
> 1340-1 - say prefixing “MH_” to the definitions, but I’m not sure about the
> options-generator and renderer lines.
>

No. these lines define the options-generator to be a procedure with no
arguments i.e. lambda () that calls (multicol-report-options-generator
'pnl). The 'pnl is used to direct the multicol-report-options-generator to
provide options suitable for profit-n-loss aka 'pnl. See the definition of
multicol-report-options-generator and locate where 'pnl is tested.


> uuidgen on my Mac issues 36-character uuids, with hyphens and uppercase,
> like this:
> 47170C69-F87E-4A3B-9A97-8B97F56F5DFD
> Would I need to edit them to give 32-character lowercase uuids, lacking
> hyphens?
>

Actually any unique string of any length will do.


> Obviously, I have to take responsibility for my own programming
> experiments (and errors), but I’d appreciate a quick steer from someone
> with Scheme experience. Regards,
> Michael
>

Good luck!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] A little hint for xcode usage (scheme)

[Christopher Lam]

Emacs + magit + ripgrep does all we need...


On Mon, 9 Mar 2020, 11:44 am Mike Alexander,  wrote:

> I used to use XEmacs much like John describes, although I did use the
> debugging mode in XEmacs.  That was long enough ago that lldb wasn't
> around, at least not for what I was working on.  Now I use XCode for
> debugging and BBEdit for editing.  They work together pretty well and
> XCode's debugging GUI is quite nice.  I remember debugging using address
> stops and console switches, so this is a big step up.
>
> Mike
>
> On 8 Mar 2020, at 23:27, John Ralls wrote:
>
> > From the command line, lldb bin/gnucash
> >
> > br se -n foo
> > or you can use the gdb compatibility version, b foo.
> >
> > emacs gud mode apparently doesn't support lldb and I've never bothered
> > to try anyway. I do sometimes wish for compiling in emacs when I'm
> > working through 400 lines of template errors, but so far not enough to
> > figure out how to import all of the necessary environment to make it
> > work. Immediate productivity always seems more important than taking a
> > week to learn a new tool.
> >
> > I'm occasionally tempted to consider switching to bbedit or vscode,
> > but after 35 years of emacs it would be a lot of learning time that
> > could be spent on more useful things.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnc:debug changes

[Christopher Lam]

On Sat, 7 Mar 2020 at 06:18, Mike Alexander  wrote:

> I understand. Avoiding the call to strify is a good idea and I don't
> intend to change that. I was simply pointing out that evaluating the args
> to gnc:debug may also take some time. In the case you mention presumably
> pricelist already exists, but sometimes the debug output has to be created
> by calling other functions which can take time. I don't think it's possible
> to avoid that by changing gnc:debug, at least not easily.
>
Ok I think your changes are fine. I don't understand qof_log_check I'd hope
it's not slow.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnc:debug changes

[Christopher Lam]

Hi Mike.

I'd thought that the log level would be an invariant per session. If log
levels could be amended mid-session I'd like to see how.

The gnc:debug was optimized because there was (gnc:debug pricelist) whereby
a long pricelist (which is realistic) would obligatorily lead to
string-join and map in strify, and was definitely a *major* slowdown.
Conclusion: we don't want to call strify with a long list unnecessarily.

If log level is not an invariant, assuming qof_log_check is fast, would be:

(define (gnc:debug items)
  (when (qof-log-check "gnc" QOF-LOG-DEBUG)
(gnc-scm-log-debug (strify items


On Sat, 7 Mar 2020 at 05:25, Mike Alexander  wrote:

> I spent some time yesterday figuring out why gnc:debug never produced
> any output regardless of the gnc.scm log level.  I tracked it down to
> commits 42b6fb9 and b3a4cd6 from last July.  The actual bug is trivial
> (they test for the log level for "gnc" instead of "gnc.scm") but I
> wonder if b3a4cd6 is a good idea.  It has the effect of binding the
> gnc.scm log level on the first call to gnc:debug and ignoring subsequent
> changes to it.  This means that later calls to (qof-log-set-level
> "gnc.scm" ...) will have no effect.  It is sometimes useful to turn on
> and off Scheme debugging around sections of code you care about.
>
> The optimization from b3a4cd6 seems to be relatively minor.  The
> arguments to gnc:debug are evaluated when debugging is off even with
> this change (something I verified) and the call to strify is avoided
> even without it.  All you're really avoiding is the actual call to
> gnc:debug and the call to qof-log-check.  I propose reverting back to
> 42b6fb9 with the bugs in it fixed.  Is this ok? If so I'll push a
> change.
>
>  Mike
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] importing csv multisplit multicurrency problems

[Christopher Lam]

Hi Geert

Check out xaccDisableDataScrubbing and xaccEnableDataScrubbing pair, seems
to be appropriate while importing CSV/OFX/QIF etc, and should make them
marginaly faster.

C

On Thu, 5 Mar 2020 at 17:03, Geert Janssens 
wrote:

> There are several bugs with multi-currency csv imports. I don't think it's
> currently possible to do such imports. Sorry.
>
> Geert
>
> Op donderdag 5 maart 2020 14:14:56 CET schreef Gio Bacareza:
> > I'm encountering problems with importing transactions in csv when
> accounts
> > have different currencies.
> >
> > I've been reading the debates. So this is not about definitions of
> > multi-split or terminology.
> >
> > I did a test with a sample csv with the following contents:
> >
> > Date,Description,Account,Deposit,Withdrawal
> > 1/3/2019,Description,test_foreign,,200
> > ,,Trading:CURRENCY:PHP,,10013
> > ,,Trading:CURRENCY:USD,200,
> > ,,test_local,10013,
> >
> > gnucash imported successfully but it created an extra line Imbalance-USD.
> > See results below:
> > Date   Description   Account   Deposit   Withdrawal
> > 1/3/2019   Description 200
> >   Trading:CURRENCY:USD   197.78
> >   test_local   10013
> >   Imbalance-USD   2.22
> >   test_foreign 200
> >   Trading:CURRENCY:PHP  10013
> >
> > 1. Why does it do that when imported transactions is already balanced in
> > the first place?
> > 2. When I try to manually correct in gnucash (197.78->200), it wouldn't
> > allow me. It keeps the imbalance no matter what I do.
> > 3. How do I solve this?
> >
> > Thanks,
> >
> > gio
>
>
>
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [GNC] QIF file import failed -- but no errors or warnings

[Christopher Lam]

 create the transaction, then edit each of
> the two separately  Yes.  See test5.qif -- I could edit the
> Grandma transaction to be Aunt in the entry that is in Savings1,
> and the Grandma memo did not change.  So if memos differ, we may
> still need to match the transactions, so matching rule (d) is
> a suggestion, but not necessary.
>
> Now, for Quicken, the transactions are listed in the order that
> they are in the transaction registers, and double-entry transactions
> will always be created at the same time, and so will appear in the
> same order in both lists.  So if we have a bunch of transactions
> for account 1 and account 2, for the same day, they should match
> in order (for the subset that point to each other -- you could
> have transactions from other accounts interleaved), so the amounts
> should match, and the memos "should" match (but may not).
> But QIF files, in general, would not have to be sorted that way,
> so probably best not to assume that.  If we have one transaction
> for $73.47 and another for $23.55, on the same day, and somehow
> they are in one order for one account and the other order for
> the second account, we should still match them (absent other
> transactions for those amounts for those days).  I would think
> that "most" of the time, the days and amounts make it unique
> when accounts point at each other, and order and memo are
> unnecessary.  So do we really want to code for when order and/or
> memo are deciding factors, or just match anyway.
>
> Now splits are a complicating case.
> But it seems a transaction A with splits
> 1, 2, 3 should be identical to 3 separate transactions A1, A2, A3
> in the obvious way.  So if we map splits into multiple transactions
> when things are read in,
> can we just drop the concept of a split?
>
> jim
>
>
>
> On Sat, 2020-02-22 at 22:54 +, Christopher Lam wrote:
> > Re: duplicate internal transfers -- I guess would be difficult in any
> > software. Consider the following transactions, *all* in the same book --
> and
> > *all* accounts (bank chequing, savings1, savings2) are selected for QIF
> > exports.
> >
> > 10/01/20 Save $100
> > Chequing -$100
> > Savings1 +$100
> >
> > 10/01/20 Save $100
> > Chequing -$100
> > Savings1 +$20
> > Savings2 +$80
> >
> > 10/01/20 Save $100
> > Chequing -$100
> > Savings2 +$100
> >
> > The QIF will have:
> > chequing
> >  10/01/20 -100 save $100
> >  10/01/20 -100 save $100
> >  10/01/20 -100 save $100
> > savings1
> >  10/01/20 +20 save $100
> >  10/01/20 +100 save $100
> > savings2
> >  10/01/20 +80 save $100
> >  10/01/20 +100 save $100
> >
> > And somewhere internal *must* contain logic to marry up the 7 splits
> into 3
> > separate transactions *without* an unique transaction_ID. I don't think
> it's
> > possible to make one safely. The easy answer is to export each account
> into
> > a separate QIF, and import piecemeal. i.e. after importing chequing.qif,
> > import savings1.qif and match the transactions manually, then
> savings2.qif.
> > Even then I'm not 100% sure the gnucash QIF importer or any other
> software
> > can handle this safely.
> >
> > On Sat, 22 Feb 2020 at 19:03, James Peterson  wrote:
> > > I'm seeing generic problems with QIF importing with
> > > both gnucash and Kmymoney and I think skrooge too,
> > > that can't handle the semantics of my QIF file.  For
> > > example with splits and unassigned categories and
> > > such.  Also, Quicken seems to assume an unnamed cash
> > > balance for investment accounts as the source and
> > > destination for buy/sell/interest/dividends, which
> > > no one seems to handle properly.
> > >
> > > So I'm currently planning to write a QIF to QIF
> > > program that will "clean up" and "simplify" these
> > > sorts of things.  It can create a named account for
> > > the anonymous cash balance (which seems to be what
> > > the brokerages are doing anyway), delete zero balance
> > > and empty lines, and output a new QIF that doesn't
> > > have these problems.  Don't know what I can do about
> > > duplicate internal transfers -- that's sort of the
> > > core of double-entry bookkeeping.
> > >
> > > I started by looking in github for "QIF file" and
> > > have 130 different programs which take in or produce
> > > QIF files, so I'll review those first, although most
> > > of those se