Re: [GNC-dev] ANNOUNCE: GnuCash 5.6 Released
Thanks to John and all the team. Builds and runs with no obvious problems from the tarball on Linux Mint 21.3. David Cousens On Sun, 2024-03-31 at 16:34 -0700, John Ralls wrote: > The GnuCash development team announces GnuCash 5.6, the seventh > release in the stable 5.x series. > Between 5.5 and 5.6, the following bugfixes were accomplished: > > Bug 798946 - start/end of current/last quarter have off-by-one > error > Bug 799093 - Cannot reconcile since v5.4 > Bug 799179 - SLR won't allow change from "Reminder" to any other > state > Bug 799210 - Bad encoding of accented chars in account names in > "Import CSV" wizard > Bug 799213 - SIGSEGV caused by revising an auto completed > transaction > Bug 799222 - Crash when changing the parent of an account that > has had two or more levels of sub-accounts auto-created using the > register in the current session. > Bug 799224 - Import of QIF gets Bug detected during duplicates > (partial fix: If the new-splits object is null, it means the new > account tree from the current import has no splits. Therefore the > (apply min|max dates) will fail. Omitting the date query is a simple > fix to prevent crashing. This is a partial fix because the crash is > likely a symptom of another bug which causes the new account-tree to > be empty. > Bug 799225 - QIF Importer Crashes Silently after "Start Import" > Button: Don't allow a QIF investment transaction without an action > (buy/sell/etc) > Bug 799246 - import matcher will rename incorrect splits > > The following fixes and improvements were not associated with bug > reports: > > Numeric parsing and string handling improvements in the Engine > and XML backend. > [gnc-dense-cal.c] sx popup: show date in preference (cf.locale) > format because the date format preference is user-facing and > customisable. it's jarring if the preference is dd/mm/ and the > display shows mm/dd/ in accordance to the locale. > Correct misleading description about creating Scheduled > Transaction. > Date parsing efficiency improvements. > Update minumum Python version to 3.8, made necessary by updating > the C API in the Python bindings. > Replace deprecated distutils.sysconfig with sysconfig. distutils > is not present in Python 3.12.2. > Query user via dialog for date when creating a reverse > transaction. > More C++ conversions > Avoid deprecation warning for -py3 in swig >= 4.1 > [gnc-commodities.cpp] gnc_new_iso_codes is a std::unordered_map > Replace some naked for loops with C++ algorithms > Convert gnc-commodity to C++ and make GncQuoteSources a C++ > class. > [test-commodities.cpp] add some tests for gnc_quote_sources > Remove the SLR status sort as it is too confusing > Allow sorting of the transaction column in the Since Last Run > dialog by schedule name or occurrence date. To sort by schedule name, > a schedule name is first selected and then the column header is > pressed to change order. To sort by occurrence date, a date is > selected and then the column header is pressed to change order based > on the date of the first occurrence. A tool tip has been added to > indicate the sort order being used. > [gtest-gnc-numeric] add operator comparisons with example int64 > numbers > [assistant-stock-transaction] store & retrieve associated account > as metadata > Update Form/Schedule line references for 2023 for the US Income > Tax Report > Update another gnucash-help to gnucash-manual > [invoice.scm] centralize layout components into layout-key-list > instead of maintaining 2 assoc lists. > [invoice.scm] normalize header section generators, changing the > functions to require 1 options argument only > Update invoice.scm: Add spacing for long Invoice ID's (Displayed > as "Reference" on the Invoice) > > New and Updated Translations: Croatian, Dutch, English (Australia), > English (New Zealand), English (United Kingdom), French, German, > Hebrew, Hungarian, Indonesian, Japanese, Norwegian Bokmål, Polish, > Portuguese, Slovak, Spanish, Swedish > > Help translate GnuCash on Weblate > Help translate GnuCash on Weblate: > https://hosted.weblate.org/engage/gnucash/ > > Known Problems > > Complete list of all open bugs: > https://bugs.gnucash.org/buglist.cgi?bug_severity=blocker_severity=critical_severity=major_severity=normal_severity=minor_severity=trivial_status=NEW_status=ASSIGNED_status=NEEDINFO_status=REOPENED=0_id=8149=priority%2Cbug_severity_format=advanced > > Documentation > > Between 5.5 and 5.6, the following bugfixes were accomplished: > > Bug 7992
Re: [GNC-dev] Datev import filter
Stefan, The Datev format is a CSV format. It should be possible to simply assign the Headers to the appropriate columns in the Datev file I can't remember if the CSV importer remembers the header assignments to specific columns but I think it does and if it does this can be stored as an input format and used whenever you wish to import Datev files. The assignment of the external account number to an account in GnuCash should only have to be done once unless that association changes. On Mon, 2023-11-06 at 12:24 +0100, Stefan Nunninger wrote: > Hello, > > By now GnuCash does not allow the import of Datev files. Datev is the > most widely used accounting software for tax professionals in Germany > and maybe other countries as well. So I guess it would be a very helpful > feature for GC. > > I am working currently on an import filter to import transaction data in > Datev format to GC. > My approach is to first convert the Datev file into a csv file that is > conform to the GC export format. > Then in a second step I import the data with the standard GC import filter. > > I got this approach running with some limitations. > Currently the account number gets not automatically assigned in GC, even > though I use the same numbers as in GC. The assignment of the columns in > the csv file has to be done manually too. > I guess this can be improved to work better. > > Is there interest to integrate my Datev import filter to GC to provide > this functionality to other users? > If so, how would you want this to be implemented? > I would be glad to discuss this topic with people who are acquainted > with the GC import/export filters. > > Best regards > Stefan > > ___ > 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] ANNOUNCE: GnuCash 5.4 Released
Thanks John and all the team. Happily runnng 5.4 on Linux Mint 21.1 David Cousens On Sun, 2023-09-24 at 14:26 -0700, 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-ofx-import.c, import-parse.c, import-utilities.c, import- > format-dialog.c, import-account-matcher.c, import-commodity-matcher.c, import- > settings.c, import-pending-matches.c, import-match-picker.c, import-main- > matcher.c, and gnc-pricedb.c to .cpp > By default, filter out online_wiggle in test-gnc-quotes. Running > ./bin/test-gnc-quotes from the command line will still include online_wiggl
Re: [GNC-dev] v5 breaks multicol reports, why didn't someone check this behavior?
Wm, The problem arises because you opened your original post with this: "The problem is the fuckwit in charge there doesn't allow reports from people that don't suck his penis." Just point out the problem with the program - we neither want, need or care for your personal vitriol and feelings of inadequacy. That only serves to divert attention away from the problem that needs to be fixed and you become the problem. If you can't fix it, just tell those who can what the problem is and let them get on with it. David Cousens On Tue, 2023-05-09 at 18:10 +0100, Wm wrote: > Since I know as fact that v5 is making a mistake WHY THE FUCK is this > nagging incorrect message allowed into the group? > > FFS when *I* point out a mistake *I* get complaints, jeez :( > > Have some decency and honesty folks ! > > Wm ... > > On 2023-05-09 15:42, Mark wrote: > > May 9, 2023 07:50:26 Wm : > > > Wm ... > > I understand that you're frustrated when you encounter bugs, but please > > remember, Gnucash is developed by volunteers. They are developing software > > and fixing bugs because they enjoy it, they are not, as far as I know, under > > any contractual obligation to you. With that in mind, if you want someone to > > feel motivated to fix a bug, a polite message that details how to reproduce > > the bug would have better results than the message you sent. > > > > Thanks, > > Mark > > ___ > 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 % Build on Linux MInt
Thanks Geert, I usually build from the tarball but for some reason wasn't able to download it from the website yesterday so I tried downloading it from Github. David On Tue, 2023-03-28 at 20:34 +0800, Geert Janssens wrote: > The big difference is a git clone can generate de required file because the > needed info is in the clone metadata. The zip file is automatically generated > by github. We don't control this and unfortunately it doesn't contain the info > the build needs. For that reason each release is accompanied with a release > tarball, generated by the gnucash developers themselves and that does have > the missing file. You can find links to the tarball in the release > announcements. > > Regards, > > Geert > > David Cousens schreef op 28 maart 2023 14:23:24 > GMT+08:00: > > That worked for me too Stephen, thnaks. > > > > The missing file is still not there in the git clone of the repository, so > > either the cmake is looking for and finding it it elsewhere but the > > downloaded > > ZIP still isn't compiling. > > Cheers > > David > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > Sent from my smartphone. Please excuse my brevity. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Gnucash % Build on Linux MInt
That worked for me too Stephen, thnaks. The missing file is still not there in the git clone of the repository, so either the cmake is looking for and finding it it elsewhere but the downloaded ZIP still isn't compiling. Cheers David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Gnucash % Build on Linux MInt
Hi Just attempted to build GnuCash 5.0 on Linux Mint 21.1 from the tarball downloaded from Github cmake ran without errors but ninja gave the following error: "ninja: error: '../libgnucash/core-utils/gnc-vcs-info.h', needed by 'libgnucash/core-utils/CMakeFiles/gnc-vcs-info', missing and no known rule to make it" Any clues? Regrads David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Build error
D It may help more if you can tell us what OS and version you are building on
and the version of GnuCash you are building. There are usually 3 steps in the
build:
1 Running "cmake" to set up the build
2 Running "make" or "ninja" to build the libraries and program
3 Running "ninja install" to install the program (this can be either a local
install to your home directory or installed system wide for all users).
If you have previously built GnuCash with failures, it is a good idea to delete
the build directory before rebuidling
The build on Linux instructions are still up to date AFAIK. The reports are
generally separate from the main program and are written in Scheme/Guile and the
guile interpreter runs within GnuCash. To change and customize reports should
not require you to rebuild GnuCash itself. (see
https://wiki.gnucash.org/wiki/Custom_Reports ).
From the directory structure you appear to be building on a Linux variant. The
cmake output to the terminal will tell you if you are missing any dependencies.
You may need to enable the deb-src module in your software sources as others
have noted, particularly to use the sudo apt build-dep gnucash command. In some
linux repositories, the dependencies headers don't always have the generic
libraries names
apt-cache search where string is a n extract from the generic library
name can usually help locate the appropriate development headers in a particular
Debian/Ubuntu derivative
David Cousens
On Thu, 2023-01-05 at 22:18 +0100, ml enquirer wrote:
> Hi,
>
> Thanks for all your hard work on gnucash; it's fantastic.
>
> To try and debug some budget reporting issues I'm having (
> https://lists.gnucash.org/pipermail/gnucash-user/2023-January/104734.html),
> I'm trying to build for the first time. I *think* I installed all the
> dependencies, but I'm running up against the following build error.
>
> Is it obvious to you what I must be doing wrong? Could it be related to the
> fact that I'm trying to build on a system that already has gnucash
> installed? I see notes during compilation like:
> ;;; note: source file dir>/gnucash/gnucash-
> build/share/guile/site/3.0/gnucash/reports/standard/trial-balance.scm
> ;;; newer than compiled
> /usr/lib/guile/3.0/site-ccache/gnucash/reports/standard/trial-balance.go
>
> Many thanks,
> D
>
> ```
> Backtrace:
> In /usr/bin/guild:
> 72:17 19 (main _)
> In srfi/srfi-1.scm:
> 634:9 18 (for-each # …)
> In scripts/compile.scm:
> 279:27 17 (_ _)
> In system/base/target.scm:
> 65:6 16 (with-target _ _)
> In system/base/compile.scm:
> 187:6 15 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ …)
> 53:4 14 (call-with-output-file/atomic _ _ _)
> In ice-9/boot-9.scm:
> 1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> In system/base/compile.scm:
> 69:11 12 (_)
> 190:11 11 (_ #)
> 331:39 10 (read-and-compile # #:from _ …)
> 261:27 9 (_ _ _)
> In ice-9/boot-9.scm:
> 2836:4 8 (save-module-excursion #)
> In language/scheme/compile-tree-il.scm:
> 31:16 7 (_)
> In ice-9/psyntax.scm:
> 1218:36 6 (expand-top-sequence (#) …)
> 1210:19 5 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
> 259:10 4 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
> In unknown file:
> 3 (load-extension "libgnc-gnome" "scm_init_sw_gnome_module")
> In system/foreign-library.scm:
> 190:25 2 (load-foreign-library _ #:extensions _ # _ #:search-path …)
> In unknown file:
> 1 (dlopen "/usr/lib/libgnc-gnome.so" 1)
> In ice-9/boot-9.scm:
> 1685:16 0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure dlopen: file "/usr/lib/libgnc-gnome.so", message
> "/usr/lib/libgnc-gnome.so: undefined symbol: gnc_get_euro"
> ```
> ___
> 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.13 Released
Thanks John and all the team for the hard work and a new version. Built from the tarball and runs with no obvious problems on Linux Mint Vanessa. David Cousens On Sun, 2022-12-18 at 15:07 -0800, John Ralls wrote: > The GnuCash development team announces GnuCash 4.13, the fourteenth release in > the stable 4.x series > > Between 4.12 and 4.13, the following bugfixes were accomplished: > > • Bug 760274 - The Statusbar "forgets" when register doesn't have > focus > • Bug 798545 - Crash when updating document link on vendor bill > • Bug 798614 - Croatia to join the Euro > • Bug 798629 - gnucash crashes attempting to import OFX file > • Bug 798633 - 4.12 build failure on 32-bit Linux: "No code for > module" > • Bug 798640 - Segfault when running saved report > • Bug 798649 - Crash when closing Edit Style Sheets dialog while Style > Sheet Properties dialog is still open. > • Bug 798653 - Schedule Calendar event description pop up window does > not track mouse position > • Bug 798657 - Import Summary language is wrong > • Bug 798664 - Result of 'gnucash --nofile' is marked dirty > • Bug 798669 - Multicolumn Balance Sheet not printing exchange rates > include equity accounts in the exchange rate commodities list. > > • Bug 798672 - Preferences are not saved nor loaded, ERROR > g_settings_new_full: assertion 'schema != NULL' failed > • Bug 798680 - Not able to match a reverse transaction of a previously > matched transaction. > • Bug 798681 - Previously imported investment income transactions may > not be filtered. > • Bug 798694 - Cursor in the wrong place after pasting with auto- > completion > The following fixes and improvements were not associated with bug reports: > > • Don't normalize text when pasting from the clipboard or appending > descriptions or notes during imports. > • [register] Delay post-ime reset of the selection to works around bug > 798587. > • [ofx import] Clean up importing investment transactions for smoother > workflow and better UI behavior. > • [account-piecharts] drill-down piechart: tree-depth is at most 6 > • Fix numerous memory leaks. > • [ifrs-report] From Bug 798004 allow Cr cash to offset Dr fee and > remove invalid "dividend reinvestment" during short. > • [gtest-qofevent.cpp] Add comprehensive tests for qofevent > • [test-qofbook] Test that gnc_features_test_unknown returns a > suitable error message > • [test-qofbook.c] add test for gnc_features_set_unused > • [gnc-features.cpp] backport gnc_features_set_unused from master > • [qofbook.cpp] backport qof_book_unset_feature from master > • Move gnc-euro.[ch] to engine and unit test it. > • [test-qofbook] basic features test: Sets a feature and tests it's > set. it's impossible to design a book with unknown features using the API. > • po/README: Remove relics from ancient context forms > • [test-ifrs-cost-basis] amend tests to accommodate extra column. > • [ifrs-cost-basis] compare register vs calculated capgain per > transaction. > • Accomodate WebKit package version update to webkit2gtk-4.1. > • [assistant-stock-transaction] input positive capgains for Credit > income account. > New API: None. > > Deprecations: > > • qof_book_get_features > New and Updated Translations: Chinese (Simplified), Croatian, English > (Australia), English (New Zealand), English (United Kingdom), French, > Hungarian, Indonesian, Japanese, Korean, Macedonian, Polish, Spanish, Urdu > > Help translate GnuCash on Weblate > > Known Problems > > Complete list of all open bugs. > > Documentation > > Concurrent with the release of GnuCash 4.13 we're pleased to also release a > new version of the companion Help and Tutorial and Concepts Guide > > Between 4.12 and 4.13, the following bugfixes were accomplished: > > • Bug 798620 - Unable to build docs on Mageia Cauldron > • Bug 798623 - ENG. Typo "documenation" > • Bug 798624 - Document how to check if GnuCash is running when > updating quotes > • Bug 798645 - screens instead of WINDOWS > • Bug 798665 - New: ENG. Typo: Unnecessary determiner "a" [2.6.1. > Migrating financial data] > • Bug 798674 - Broken link on Chapter 17. Python Bindings > The following fixes and improvements were not associated with bug reports: > > • Manual Account_Actions: Tippfehler-Korrektur > • Review URLs and replace them by entities in all parts and la
Re: [GNC-dev] Dependencies policy for major releases
John, I usually build the latest release from the source code on Linux Mint (currently 21.3) as soon as a new release comes out. My desktop is getting a bit ancient but still has no problem with Linux. I also run the Windows version on my wife's laptop (Windows 11). Not averse to having to build dependencies from scratch on Linux if I have to but would prefer not to where possible. I tried Flatpak early on when there was a bit of extra setup to configure access to the system resources but haven't been back now that most of those have likely been sorted. David Cousens ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Book advertised on help manual online
Liz, The book is available from booksellers like Booktopia online as well as direct from the publishers. Does anyone know Ashok Ramachandran or know how to contact him? For example he might be interested inproducing an updated edition for GnuCash 4.x for example? A new version could be written from scratch but it would probably make more sense to update the original. An Ashok Ramachandran (Australian citizen) was recently appointed CEO of Schindler India. I don't know if he is the same person however. David On Tue, 2021-01-12 at 08:51 +1100, Liz wrote: > https://gnucash.org/viewdoc.phtml?rev=4=C=help > > I've just deflected a post to this list complaining that the link to > buy the book Gnucash 2.4 Small Business Accounting is not sending this > person to somewhere they can actually buy the book. Disregarding why > Packt's site is not working for this person, should we be still > advertising a 10 year old book for Gnucash, which is 2 full revisions > old? > > The intent of my reply was to refer this person to gnucash-user. I've > got a copy of the book "somewhere". Having moved house since I bought > it I don't know where it is, so can't really look at it to check my > facts. > > Some more views on whether we should still be advertising this book? > > Liz > ___ > 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] Search in General Ledger
Bruce, The problems building in Linux Mint 20 related to the version of the libmysqlclient21 library which was present in both the ubuntu 20.04 and Linux Mint 20 releases by default. If the version of Peppermint is based on the same Ubuntu release it may be subject to the same problem. I fixed it as described in a post in that thread by downgrading the above library to a slightly earlier version. If Peppermint is based on the same ubuntu release, the same fix should work as it likely uses the same ubuntu repository. David On Wed, 2020-08-05 at 18:42 +, Bruce Irving via gnucash-devel wrote: > I do most of my entry in General Ledger and I still haven't taught myself to > start another GL BEFORE I do a search. > Would it be possible, sometime down the road, to have the search in GL open a > new tab like the Registers do? > Off the subject: I see someone was having difficulty building GNC in Mint. > Should I expect the same in Peppermint > (Ubuntu)? I've only recently started using GCC; most of my work was a very > (extremely) liberal C compiler in DOS and > the early windows which I never did learn how to work with. Also, if > possible, I'd just as soon leave out the > importing from banks, etc. > > Bruce > Preach the Gospel wherever you go. > If necessary, use words. > ___ > 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] Build Fail for GC 4.1 on Linux MInt 20
Thanks John That was indeed the problem. Downgrading libmysqlclient21 from 8.0.21ubuntu0.20.04.3 to 8.0.19-0ubuntu5 (sudo aptitude install libmysqlclient21=8.0.19-0ubuntu5) did the trick as per this bug report on Ubuntu re the opencv package, https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/1890170 . 4.1 then built from the tarball with no problems. Apparently on LM/Ubuntu aptitude is a better choice for downgrading than apt since it doesnt attempt to uninstall dependencies. This was from a 2012 post so that problem with apt may have been addressed by now. Cheers David On Sun, 2020-08-02 at 20:40 -0700, John Ralls wrote: > David, > > The problem is very likely that Mint uses MySQL and MySQL-8 has dropped the C > connector. Libdbi-drivers is no longer > being maintained so there's no way to use the C++ connector that MySQL has > replaced it with. Your best bet for now is > probably to change to a distro that uses MariaDB as that appears to be > unaffected for now. > > Regards, > John Ralls > > > On Aug 2, 2020, at 8:16 PM, David Cousens wrote: > > > > John, Frank, > > > > Not sure what is happening here. Wehn Linux Mint 20 was released it was > > released with GnuCash 4.0 so someone > > succeeded > > in building it. I'v put a queston on the Mint forums to see if anyone there > > has had a similar proble. The same patch > > versions of libdbi and the drivers are in the Ubuntu Focal release as well > > so i would have expected others to have > > had > > problems if it was something general. > > > > David > > > > On Sat, 2020-08-01 at 10:06 -0700, John Ralls wrote: > > > > On Jul 31, 2020, at 9:15 PM, David Cousens > > > > wrote: > > > > > > > > Has anyone had any problems building GC 4.1 on Linux (Mint 20 Ulyana)? > > > > Cmake completes without problems, but I > > > > am > > > > getting multiple errors during the ninja build related to the database > > > > backend libraries: > > > > > > > > libdbi: Failed to load driver: > > > > /usr/lib/x86_64-linux-gnu/dbd/libdbdmysql.so > > > > wrote > > > > `/home/david/Applications/gnucash-4.1/build/lib/x86_64-linux-gnu/guile/3.0/site- > > > > ccache/gnucash/deprecated/gnucash/report/payables.go' > > > > > > > > The default versions on LM20 of libdbi and the libdbd modules are: > > > > dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > > > > 8ubuntu1 amd64MySQL > > > > database server driver for libdbi > > > > ii libdbd-pgsql:amd64 0.9.0- > > > > 8ubuntu1 amd64PostgreSQL database server > > > > driver for libdbi > > > > ii libdbd-sqlite3:amd640.9.0- > > > > 8ubuntu1 amd64SQLite3 > > > > database driver for libdbi > > > > ii libdbi-dev 0.9.0- > > > > 5 amd64DB > > > > Independent Abstraction Layer for C -- development files > > > > ii libdbi1:amd64 0.9.0-5 > > > > > > > > 0.8.3 of the above are the required version in the dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > > > > 8ubuntu1 amd64MySQL > > > > database server driver for libdbi > > > > ii libdbd-pgsql:amd64 0.9.0- > > > > 8ubuntu1 amd64PostgreSQL database server > > > > driver for libdbi > > > > ii libdbd-sqlite3:amd640.9.0- > > > > 8ubuntu1 amd64SQLite3 > > > > database driver for libdbi > > > > ii libdbi-dev 0.9.0- > > > > 5 amd64DB > > > > Independent Abstraction Layer for C -- development files > > > > ii libdbi1:amd64 0.9.0-5 > > > > > > > > > > > > dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > > > > 8ubuntu1 amd64MySQL > > > > data
Re: [GNC-dev] Build Fail for GC 4.1 on Linux MInt 20
Hi John, I didn't have either Mysql-8.0 or Mariadb-10.3 installed, either client or server at the time. Another user Mark reported having built 4.1 from the maint branch without any problem. I also tried going back and rebuilding 3.905 and 3.10 and had the same problem. I am trying installing both mysql-80 and mariaDB (both are available on LM 20) to see if something in the install there fixes it. Cmake doesn't throw up anything in the testing apart from gettext being 0.19.8.1 rather than 0.20. It may be something else which was previously in the default setup for LM 19 that was no longer part of 20. GC v4.0 is the default distro install and it runs fine. David On Sun, 2020-08-02 at 20:40 -0700, John Ralls wrote: > David, > > The problem is very likely that Mint uses MySQL and MySQL-8 has dropped the C > connector. Libdbi-drivers is no longer > being maintained so there's no way to use the C++ connector that MySQL has > replaced it with. Your best bet for now is > probably to change to a distro that uses MariaDB as that appears to be > unaffected for now. > > Regards, > John Ralls > > > On Aug 2, 2020, at 8:16 PM, David Cousens wrote: > > > > John, Frank, > > > > Not sure what is happening here. Wehn Linux Mint 20 was released it was > > released with GnuCash 4.0 so someone > > succeeded > > in building it. I'v put a queston on the Mint forums to see if anyone there > > has had a similar proble. The same patch > > versions of libdbi and the drivers are in the Ubuntu Focal release as well > > so i would have expected others to have > > had > > problems if it was something general. > > > > David > > > > On Sat, 2020-08-01 at 10:06 -0700, John Ralls wrote: > > > > On Jul 31, 2020, at 9:15 PM, David Cousens > > > > wrote: > > > > > > > > Has anyone had any problems building GC 4.1 on Linux (Mint 20 Ulyana)? > > > > Cmake completes without problems, but I > > > > am > > > > getting multiple errors during the ninja build related to the database > > > > backend libraries: > > > > > > > > libdbi: Failed to load driver: > > > > /usr/lib/x86_64-linux-gnu/dbd/libdbdmysql.so > > > > wrote > > > > `/home/david/Applications/gnucash-4.1/build/lib/x86_64-linux-gnu/guile/3.0/site- > > > > ccache/gnucash/deprecated/gnucash/report/payables.go' > > > > > > > > The default versions on LM20 of libdbi and the libdbd modules are: > > > > dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > > > > 8ubuntu1 amd64MySQL > > > > database server driver for libdbi > > > > ii libdbd-pgsql:amd64 0.9.0- > > > > 8ubuntu1 amd64PostgreSQL database server > > > > driver for libdbi > > > > ii libdbd-sqlite3:amd640.9.0- > > > > 8ubuntu1 amd64SQLite3 > > > > database driver for libdbi > > > > ii libdbi-dev 0.9.0- > > > > 5 amd64DB > > > > Independent Abstraction Layer for C -- development files > > > > ii libdbi1:amd64 0.9.0-5 > > > > > > > > 0.8.3 of the above are the required version in the dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > > > > 8ubuntu1 amd64MySQL > > > > database server driver for libdbi > > > > ii libdbd-pgsql:amd64 0.9.0- > > > > 8ubuntu1 amd64PostgreSQL database server > > > > driver for libdbi > > > > ii libdbd-sqlite3:amd640.9.0- > > > > 8ubuntu1 amd64SQLite3 > > > > database driver for libdbi > > > > ii libdbi-dev 0.9.0- > > > > 5 amd64DB > > > > Independent Abstraction Layer for C -- development files > > > > ii libdbi1:amd64 0.9.0-5 > > > > > > > > > > > > dpkg -l | grep libdbi > > > > ii libdbd-mysql:amd64 0.9.0- > >
Re: [GNC-dev] Build Fail for GC 4.1 on Linux MInt 20
Thanks Mark Whatever the problem I have is, it doesn't appear to be the libdbi and libdbd drivers themselves that are the problem. I will have to dig a bit deeper. It must be an interaction with another package I have installed. I am building from the tarball at the moment but I will give it a try with maint. Cmake is not showing any problem just ninja during the build. David On Sat, 2020-08-01 at 05:55 -0400, Mark wrote: > I built on LM20 from maint yesterday and had no problems from cmake or ninja: > 2065 > lsb_release -a > No LSB modules are available. > Distributor ID: Linuxmint > Description: Linux Mint 20 > Release: 20 > Codename: ulyana > > 2011 > /opt/bin/gnucash --version > GnuCash 4.1 development version > Build ID: git 4.1-8-g5a8d04948+(2020-07-31) > > 2061 > dpkg -l |grep libdbi > ii libdbd-sqlite3:amd64 0.9.0-8ubuntu1 > amd64SQLite3 database driver > for libdbi > ii libdbi-dev 0.9.0-5 >amd64DB > Independent Abstraction Layer for C -- development files > ii libdbi-perl:amd64 1.643-1 > amd64Perl Database > Interface (DBI) > ii libdbi1:amd64 0.9.0-5 >amd64DB Independent > Abstraction Layer for C -- shared library > > > I can send you my complete output from cmake and ninja if that would help. > > cheers, > Mark > episte...@gmail.com > (613) 447-5385 > > On Sat, Aug 1, 2020 at 12:51 AM Frank H. Ellenberger > wrote: > > Hello David, > > > > > > > > On Opensuse Tumbleweed I have no problems to build commit c4d9ca7. It is > > > > also using libdbi* 0.9.0, but the patch levels, are not comparable. > > > > > > > > Other users of the Ubuntu repositories? > > > > > > > > Regards > > > > Frank > > > > > > > > Am 01.08.20 um 06:15 schrieb David Cousens: > > > > > Has anyone had any problems building GC 4.1 on Linux (Mint 20 Ulyana)? > > > Cmake completes without problems, but I am > > > > > getting multiple errors during the ninja build related to the database > > > backend libraries: > > > > > > > > > > libdbi: Failed to load driver: > > > /usr/lib/x86_64-linux-gnu/dbd/libdbdmysql.so > > > > > wrote > > > `/home/david/Applications/gnucash-4.1/build/lib/x86_64-linux-gnu/guile/3.0/site- > > > > > ccache/gnucash/deprecated/gnucash/report/payables.go' > > > > > > > > > > The default versions on LM20 of libdbi and the libdbd modules are: > > > > > dpkg -l | grep libdbi > > > > > ii libdbd-mysql:amd64 > > > 0.9.0-8ubuntu1 amd64 > > MySQL > > > > : > > > > ___ > > > > 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] Build Fail for GC 4.1 on Linux MInt 20
John, Frank, Not sure what is happening here. Wehn Linux Mint 20 was released it was released with GnuCash 4.0 so someone succeeded in building it. I'v put a queston on the Mint forums to see if anyone there has had a similar proble. The same patch versions of libdbi and the drivers are in the Ubuntu Focal release as well so i would have expected others to have had problems if it was something general. David On Sat, 2020-08-01 at 10:06 -0700, John Ralls wrote: > > On Jul 31, 2020, at 9:15 PM, David Cousens wrote: > > > > Has anyone had any problems building GC 4.1 on Linux (Mint 20 Ulyana)? > > Cmake completes without problems, but I am > > getting multiple errors during the ninja build related to the database > > backend libraries: > > > > libdbi: Failed to load driver: /usr/lib/x86_64-linux-gnu/dbd/libdbdmysql.so > > wrote > > `/home/david/Applications/gnucash-4.1/build/lib/x86_64-linux-gnu/guile/3.0/site- > > ccache/gnucash/deprecated/gnucash/report/payables.go' > > > > The default versions on LM20 of libdbi and the libdbd modules are: > > dpkg -l | grep libdbi > > ii libdbd-mysql:amd64 0.9.0- > > 8ubuntu1 amd64MySQL > > database server driver for libdbi > > ii libdbd-pgsql:amd64 0.9.0- > > 8ubuntu1 amd64PostgreSQL database server > > driver for libdbi > > ii libdbd-sqlite3:amd640.9.0- > > 8ubuntu1 amd64SQLite3 > > database driver for libdbi > > ii libdbi-dev 0.9.0-5 > > amd64DB > > Independent Abstraction Layer for C -- development files > > ii libdbi1:amd64 0.9.0-5 > > > > 0.8.3 of the above are the required version in the dpkg -l | grep libdbi > > ii libdbd-mysql:amd64 0.9.0- > > 8ubuntu1 amd64MySQL > > database server driver for libdbi > > ii libdbd-pgsql:amd64 0.9.0- > > 8ubuntu1 amd64PostgreSQL database server > > driver for libdbi > > ii libdbd-sqlite3:amd640.9.0- > > 8ubuntu1 amd64SQLite3 > > database driver for libdbi > > ii libdbi-dev 0.9.0-5 > > amd64DB > > Independent Abstraction Layer for C -- development files > > ii libdbi1:amd64 0.9.0-5 > > > > > > dpkg -l | grep libdbi > > ii libdbd-mysql:amd64 0.9.0- > > 8ubuntu1 amd64MySQL > > database server driver for libdbi > > ii libdbd-pgsql:amd64 0.9.0- > > 8ubuntu1 amd64PostgreSQL database server > > driver for libdbi > > ii libdbd-sqlite3:amd640.9.0- > > 8ubuntu1 amd64SQLite3 > > database driver for libdbi > > ii libdbi-dev 0.9.0-5 > > amd64DB > > Independent Abstraction Layer for C -- development files > > ii libdbi1:amd64 0.9.0-5 > > > > README.dependencies specifies v0.8.3 of the above libraries. Does anyone > > else have problems building with 0.9.0 or > > will > > I have to revert? > > Libdbi 0.9.0 has been out for almost 10 years and is what most distros have > been shipping since. That's not the > problem. More likely is that MySQL/MariaDB got upgraded and the > libdbd-drivers didn't so libdbdmysql.so can't link > libmysql.so. > > Regards, > John Ralls > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Build Fail for GC 4.1 on Linux MInt 20
Has anyone had any problems building GC 4.1 on Linux (Mint 20 Ulyana)? Cmake completes without problems, but I am getting multiple errors during the ninja build related to the database backend libraries: libdbi: Failed to load driver: /usr/lib/x86_64-linux-gnu/dbd/libdbdmysql.so wrote `/home/david/Applications/gnucash-4.1/build/lib/x86_64-linux-gnu/guile/3.0/site- ccache/gnucash/deprecated/gnucash/report/payables.go' The default versions on LM20 of libdbi and the libdbd modules are: dpkg -l | grep libdbi ii libdbd-mysql:amd64 0.9.0-8ubuntu1 amd64MySQL database server driver for libdbi ii libdbd-pgsql:amd64 0.9.0- 8ubuntu1 amd64PostgreSQL database server driver for libdbi ii libdbd-sqlite3:amd640.9.0- 8ubuntu1 amd64SQLite3 database driver for libdbi ii libdbi-dev 0.9.0-5 amd64DB Independent Abstraction Layer for C -- development files ii libdbi1:amd64 0.9.0-5 0.8.3 of the above are the required version in the dpkg -l | grep libdbi ii libdbd-mysql:amd64 0.9.0-8ubuntu1 amd64MySQL database server driver for libdbi ii libdbd-pgsql:amd64 0.9.0- 8ubuntu1 amd64PostgreSQL database server driver for libdbi ii libdbd-sqlite3:amd640.9.0- 8ubuntu1 amd64SQLite3 database driver for libdbi ii libdbi-dev 0.9.0-5 amd64DB Independent Abstraction Layer for C -- development files ii libdbi1:amd64 0.9.0-5 dpkg -l | grep libdbi ii libdbd-mysql:amd64 0.9.0-8ubuntu1 amd64MySQL database server driver for libdbi ii libdbd-pgsql:amd64 0.9.0- 8ubuntu1 amd64PostgreSQL database server driver for libdbi ii libdbd-sqlite3:amd640.9.0- 8ubuntu1 amd64SQLite3 database driver for libdbi ii libdbi-dev 0.9.0-5 amd64DB Independent Abstraction Layer for C -- development files ii libdbi1:amd64 0.9.0-5 README.dependencies specifies v0.8.3 of the above libraries. Does anyone else have problems building with 0.9.0 or will I have to revert? Thanks David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dev's features of choice?
Jean, As always the answer comes down to the available resources to carry out the work needed vs the complexity of carrying it out. John has pointed out a number of barriers to being able to make GnuCash even more flexible than it is currentlyand facilitate addition of plugin capability for more specialized functionality, many of which are a consequence of the history of its development. Much of the user base would I think prioritise the basic accounting functionality which is highly adaptable (the use in many countries by a wide variety of amatuer and professional accountants and business attests to that) over nice but not necessarily critical features. We will of course happily accept those if they become available but this is always contingent on the availability of developers with the necessary expertise and sufficient understanding of the current code base and its historical complexities as well as having the accounting background necessary. Some of the occasional contributors like myself were/are primarily users with a little coding experience (but not professional developers) so our ability to contribute is limited by that as well as our available time. We rely on the core development team for the hard work (which we all appreciate greatly) and overall development roadmap while we mainly contribute around the edges. I detect a healthy dollop of the "if it ain't broke, don't fix it" brigade in the mix as well but mostly they will happily use new features if they meet their needs and then end up not knowing how they ever did without them. Such is life! David Cousens On Sun, 2020-07-26 at 16:50 -0700, jean laroche wrote: > But why??? > > > On 7/26/2020 3:38 PM, D. wrote: > > Jean, > > > > I think you raise a valid point. There does seem to be a tendency in the > > community to assume that a certain amount > > of inconvenience is to be expected. The reasons vary, but the underlying > > tendency remains. > > > > David T. > > > > > > Original Message > > From: jean laroche > > Sent: Sun Jul 26 17:49:47 EDT 2020 > > To: "Frank H. Ellenberger" > > Cc: GnuCash Developer > > Subject: Re: [GNC-dev] Dev's features of choice? > > > > > > > > On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote: > > > 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. > > I see a disconnect here. Some of us (John in particular) insist that GC > > is not a system for professionals, only for personal finance. > > Yet, I always hear about accounting rules, and the way it should be done > > by the book. If GC is really for the personal user, I don't understand > > how we can survive without undo/redo, and multi-select. *every* piece of > > software out there has these types of features, and they're invaluable. > > 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 -- 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
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- > >
[GNC-dev] Building GnuCash 4.0 on Linux MInt20
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
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /home/david/Applications/gnucash-4.0/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/ninja cmTC_4c855 && [1/2] Building C object CMakeFiles/cmTC_4c855.dir/src.c.o
[2/2] Linking C executable cmTC_4c855
FAILED: cmTC_4c855
: && /usr/bin/cc -DCMAKE_HAVE_LIBC_PTHREAD CMakeFiles/cmTC_4c855.dir/src.c.o -o cmTC_4c855 && :
/usr/bin/ld: CMakeFiles/cmTC_4c855.dir/src.c.o: in function `main':
src.c:(.text+0x46): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x52): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x63): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Source file was:
#include
void* test_func(void* data)
{
return data;
}
int main(void)
{
pthread_t thread;
pthread_create(, NULL, test_func, NULL);
pthread_detach(thread);
pthread_join(thread, NULL);
pthread_atfork(NULL, NULL, NULL);
pthread_exit(NULL);
return 0;
}
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/david/Applications/gnucash-4.0/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/ninja cmTC_1ab1b && [1/2] Building C object CMakeFiles/cmTC_1ab1b.dir/CheckFunctionExists.c.o
[2/2] Linking C executable cmTC_1ab1b
FAILED: cmTC_1ab1b
: && /usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create
Re: [GNC-dev] GnuCash 3.905: gwenhywfar packaging
Thanks Frank, I will add a note to the Wiki on Building on GnuCash for the Debian/Ubuntu/Mint distros as well. Micha has versions on launchpad/ubuntu for the recent Ubuntu version. I only needed libgwengui-gtk3 to get 3.905 to build. The libgwengui and libgwenhywfar packages are all available via apt which installs 4.20.0-1 in LM19.3. i will check out the LM20beta which has just been released after I get back from holidays at the end of next week. Cheers David On Thu, 2020-06-18 at 02:25 +0200, Frank H. Ellenberger wrote: > David, > > if you look in > https://github.com/aqbanking/gwenhywfar/tree/master/gui > you see a bunch of GUIs, e.g Kmymoney would use QT. > > For us it is all part of gwenhywfar. But Micha Lenk has split it > already for Debian in a bunch of subpackages: > https://packages.debian.org/testing/source/libgwenhywfar > > If you like, you can add a note in the wiki, perhaps > https://wiki.gnucash.org/wiki/Debian#Online_Banking, linked by a new > paragraph in Ubuntu#GnuCash_package? > > Regards > Frank > > Am 18.06.20 um 01:45 schrieb David Cousens: > > Hi > > > > I have just tried compiling GnuCash on Linux Mint 19.3 and I am getting a > > message that gwengui-gtk3 was not found. > > The > > directory present in the 3.10 source directory is not present in the 3.905 > > tarball although it was present in the > > 3.10 > > and 3.9 tarballs. I tried copying the gwengui-gtk3 directory from 3.9 but > > still received the error. found the > > library in > > the Ubuntu packages for 18.04 > > sudo apt update > > sudo apt install libgwengui-gtk3-dev > > then fixed the problem just in case anyone else hits this one. > > > > David Cousens > > -- 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
[GNC-dev] GnuCash 3.905
Hi I have just tried compiling GnuCash on Linux Mint 19.3 and I am getting a message that gwengui-gtk3 was not found. The directory present in the 3.10 source directory is not present in the 3.905 tarball although it was present in the 3.10 and 3.9 tarballs. I tried copying the gwengui-gtk3 directory from 3.9 but still received the error. found the library in the Ubuntu packages for 18.04 sudo apt update sudo apt install libgwengui-gtk3-dev then fixed the problem just in case anyone else hits this one. David Cousens ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] I need help building GnuCash on master
Christian >From memory I think that error occurs when you have a problem with the cmake relative addressing from the build directory to the gnucash source directory although that should be the same no matter whether you have the master or maint checked out with git. David Cousens ----- 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
Re: [GNC-dev] Fwd: Is the import match map still required?
1. Not much we can do about that. Presumably that is why the import match editor was created so that fat finger tokens can be located and deleted. I still have mixed feelings about pruning the table. Ok in the case where you have a known wrong entry as above but less sure whether taking connector tokens out will not adversely affect the ability to score higher on a phrase that is used consistently in a description/memo field for example. 2. I suspect doing this on the fly would create too much of a performance hit as some/many people have large files with thousands of transactions as GnuCash does not require new file creation annually. I would build a procedure that can be run on an account whenever desired to recreate the frequency table data from the existing transaction transfer accounts and replace the existing data. User's need to select the account to run it for and the date range from which to use transactions to construct the table for the cases where 5 years agon someone used a different account structure. Should not be too hard as the processes for tokenizing transactions already exist in the matcher code. If it can be run as a standalone then it can be tested to see what effect it will have if it was run on the fly during import. 3. Not sure on that. I think it is likely that only the transaction data is moved to the new account but not sure. The data may be all read into memory initially so it shouldn't be too hard to write it to a merged account. On the otherhand if a standalone as in 2 is created all that is needed is to execute it after the merge and Bob's your uncle. David - 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
Re: [GNC-dev] Import Map Editor - maintain position in list
Chris I think that is a good move. Having to continually refind my position in the list after deleting tokens was a real frustration while pruning the token list manually. Not touching that area. David - 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
Re: [GNC-dev] Is the import match map still required?
Christian, I haven't experimented to know whether constructing the frequency table on the fly creates a performance bottleneck or not but am guessing the original developer thought it might. It would require a detailed look at the code involved but my suspicion would be that the performance penalty is likely to be significant. My comment about bloat is that at present data is only maintained for accounts you specifically import data into and if that data is stored. If it isn't then bloat doesn't apply obviously. Any sort of generalized procedure could allow selection of accounts for which Bayesian matching is required, i.e. those for which importing is used to input data. My initial thought was that you would run it for all accounts but it is really only necessary for the specific subset of accounts into which you import data. It would then require the ability to run the procedure on an account if it occurred in import data but didn't have existing account matching data. If it is on the fly then no problem it can run whenever a new account being imported into appears in the imported data. The most common use case is probably importing data to one specific account but GnuCash is also able to specify the account being imported into in the import data itself. I haven't looked at how the frequency table is currently stored in memory but I am guessing it is constructed in memory when the data file is read in. The up-to-date aspect is one advantage and if the current procedure is changed to improve performance then that is not hampered by the presence of historical data which would be updated automatically when the procedure is run. If the table is stored as it is at present and a procedure was available to trawl the current transactions for an account then it can be kept up to date by running that procedure periodically. the use of data from manually entered transactions would then be incorporated whether on the fly or just run as required. Having a standalone procedure to trawl an existing file to update the stored data for an account would allow exploration of whether this is likely to be a significant performance hit if it was run on the fly so that could perhaps be a first step. The core part of the code to store the data has to exist in the matcher code already and it will be a case of wrapping this in a loop through the transactions existing in an account and setting up the gui interface to select accounts to run on. The problem with pruning the data is that GnuCash has no way of knowing apriori which tokens are most relevant. I would think that date information is not really relevant and amount/value information does little in most cases to identify a transfer account. The main difficulty I have with transfer account assignment is that some regular transactions use a unique code in the description each time they occur with no separate unique identifier of the transaction source. My wife and I both have separte gym membership subscriptions and the transaction descriptions neither identify the gym or for which of us the transaction applies. Options are to persuade the source to include specific data or only use a single account to record both but I like to track both our individual and joint expenses Some regular transactions also get matched to previous payments in the transaction matching within the date range window where the amounts and descriptions are usually identical. The current 42 day window captures both fortnightly and monthly regular income transactions for example. This only affects a few transactions each month and I don't have huge numbers of transactions to process now that I have retired but that may not be the case for other users. Maybe making the date range window adjustable rather than fixed might be a cure for this. Setting it at <14 days would cure the problems I have for example, but that again would not work for everybody. I am currently committed to a bit on the documentation front so I will be unlikey to consider this for the near future in other than general terms but someone else may be willing to take it up. David ----- 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
Re: [GNC-dev] Is the import match map still required?
Christian, I guess it depends on whether there is a performance advantage in using the previously stored data for the transfer account associations over constructing the frequency table on the fly. The search for matching transactions only takes place within a narrow time window around the date of import, so it is unlikely to canvas enough transactions to be able to construct a valid frequency table from tokenized data within that window. The stored frequency table would generally contain data from a much wider range of transactions and would take much longer to construct on the fly each time it was needed. I have also pondered whether it could be usefully augmented by using data from transactions entered manually which have not been imported for the file associations. Could be of value where you have a good set of historical records but it would only need a one off run through the existing transactions to gather the data. Unless you confined it to running on a specific set of accounts to which you import data it might cause bloat of the data file with unnecessary and unused information. I have examined the stored data in my data file with the import map editor and found that there was a lot of data stored which contributes little to the matching for the transfer account ( dates, connectors (a, and, the etc.), transaction amounts ?) which often have a fairly uniform frequency for all accounts which were used as transfer accounts. After a bit of pruning of the stored data my matching reliability seemed to improve a bit. I don't know at the moment if the tokens stored for transfer account matching are a subset of the tokens used for transaction matching (haven't checked) but restricting the set of tokens used may possibly improve performance and reduce the amount of data stored if all tokens associated with a transaction are currently being stored in the frequency table which is what I suspect from examining my import map data. David Cousens - 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
Re: [GNC-dev] Bootstrap Win10 Build Environment
If the wiki is out of date, on Building on Windows, it could probably do with a refresh. You just need to ask for wiki editing rights. I try and keep the Building on Linux page up to date but I don't build GnuCash on Windows. There will be some posts in the recent list archives as well. David On Tue, 2020-05-19 at 11:00 +1000, flywire wrote: > Hold that. > https://github.com/Gnucash/gnucash-on-windows/blob/master/README.md looks > much more useful than the wiki. > > > > > ___ > 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] Accounts tabheader Total (USD)
Finally found the source of my problem - setting the default currency for the reports in the Edit-Preferences->Reports tab. this is new territory for me. ----- 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
Re: [GNC-dev] Accounts tabheader Total (USD)
GC v 3.9 on Linux Mint 19.3 - 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
[GNC-dev] Accounts tab keader Total (SUD)
I was setting up a demo _book with USD as the default currency to create some updates to the documentation on multicurrency section in the guide and just duplicating the original book structure used to create the screen shots in the current documentation. I started a new book, selected USD as the default currency and created my required accounts with multiple currencies, while the locale for my computer is Australia. In the account tab I wanted to display the Total (USD), i.e. the total in the book currency in the accounts tab, however the drop down list of the headers selected using the down arrow at the right of the header row has (AUD) appended to the selectable column headers. Surely when I selected USD as the default currency in the new book dialog, this should override locale settings? In the preferences Accounts tab I deselcted the Default Currency for new accounts as Locale and selected the Choose radiobutton with USD (US Dollar), then saved the book and reopened it. No change in the above resulted although new accounts were in USD. Screenshot attached. The Opening Balances (USD) displays the correct totals if prices are set in the database Searching through the XML file I was unable to find any references to AUD so it is clearly picking up on the locale setting however changing /etc/default/locale to LANG=en_US.UTF-8 LANGUAGE=en_US.en or the same settings in /etc/gnucash/environment produced no change in behaviour after restarting GnuCash. I still get a column in AUD. David Cousens - 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
[GNC-dev] Trading Accounts 797701
In a recnt discussion with (http://gnucash.1415818.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes=378901) around capital gains and realized and unrealized gains, I had occasion to acquaint myself with trading accounts. The current version of Ch12 only deals with the manual calculation of multiple currencies and while it mentions trading accounts it is mainly by reference to peter Selinger's tutorials (https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html and https://www.mscs.dal.ca/~selinger/accounting/gnucash.html). The user became confused and i also ended up confused largely because peter Selinger's articles do not discuss the trading account implementation in GnuCash as it is now. I am proposing expanding Ch12 as per the outline in https://bugs.gnucash.org/show_bug.cgi?id=797701 to include trading accounts. David Cousens - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Dale, While that was the main thrust of the thread, it is inevitable that it will bring attention to other issues so no real dramas. The advent of electronic clearing almost immediately and OFX direct connect connections to at least some banks (mine won't cooperate) is also changing the game. An OFX directConnect query may have the status of a statement in some circumstances and an import in that can already trigger the reconciliation processand reconcile in some circumstances as John described in another post. This is still consistent with the manual reconciliation process. The discussion did encompass improvements to recording the reconciliation process, i.e a reconciliation history if you like to help with automatic checking of the account and Geert outlined an approach to that by including a statement data structure which links to the account being reconciled and has essential information about each statement which would make what I have in mind much easier down the track. I wasn't objecting to issues you raised but was more concerned that we were on the same page in terms of terminology. Not sure what an alternative approach to reconciliation would look like. As an accounting process, reconciliation is about checking your books records against those maintained by another entity and ensuring agreement. From an accounting perspective GnuCash's reconciliation process is already very good. How would you do it differently? David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Geert > From an implementation point of view I'd structure this slightly > differently: > 1. instead of adding an account property with a list of reconciliation > history, I would introduce a > new object, like a "statement" This object would have the fields you > mention before (date of > reconciliation, statement start date, statement starting balance, > statement end date) and some > more: > *statement id* - most bank statements has a unique number which may be > helpful to track > *statement ending balance* - particularly useful to verify manual > transaction entries. If you > explicitly enter a start and ending balance in addition to the > transactions themselves, amount > typos will be caught by the numbers no longer adding up. > *account" - the account this statement refers to. > > Lastly each split should get an additional field "statement id" referring > to the statement which > includes it. The split "reconciliation date" field would no longer be > necessary. That info is > encapsulated in the associated statement. > > This mapping would be much closer to the real world order of things: > * during reconciliation a split is matched to a line on a statement > * each split can be linked to only one statement > * in case of reconciliation trouble in the past, the extra statement > details make it easier to dig > up the related external source (there's a statement id in addition to a > reconciliation date). > * it is more clear which splits were reconciled together - they are tied > to the same statement, > where in the past there was only a reconciliation date, which may have > been wrong for various > reasons. I also agree that this is a good way to implemnet the idea. It meets what i had in mind for a reconciliation history much better. David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Thanks John for clarifying that. My take on that situation is that the statement start date is TODAY. The statement end date is TODAY and the reconciliation date for any included transactions is TODAY. That is obviously consistent with the manual reconciliation process. David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Adrien, I am referring specifically to setting the reconciliation date for the split you are reconciling. When a transaction is created in GnuCash both the date it was entered into Gnucash and the date it was posted are recorded in the transaction data structure and file. Only the posted date is normally displayed in the register. The posted date should of course be the date relevant to the event which you are recording in your books. The reconciliation date is separate from both of these and is part of the data structure for the split to the account being reconciled that is part of the transaction data It is currently set to the end date for the statement when the reconciliation flag for the split is set to 'y' by the reconciliation. During the import process when an existing transaction is updated from an imported record, it is set to 'c' (cleared) and TODAY, the date at which the importation occurred is recorded in the reconciliation date field. splits set to 'c' are not included in the starting balance calculation for a transaction, only those set to 'y'. WHen they are included in a reconciliation process, then they are set to 'y' and the reconciliation date field is set to the end date of the relevant statement. I believe the above is all kosher and the current situation only arises AFAIK when the user has inadvertently set the end date of a statement to a far future date as I did and then Chris's improvement in 3.9 prevents them from being included in the starting balance sum. My reference was only to the dates the bank records the transactions at in its statement not to any dates recorded for the transaction in GnuCash. I was being very pedantic in the interest of trying to make what I meant clear (but still didn't quite manage it). One problem in all these discussions is always making sure everyone is using the same terminology for the same conceptual structure/objects. I agree adjusting transactions may not have the date of the original transaction and may not necessarily fall within the period encompassing the original transaction at the date recorded in the book and could possibly have been recorded in the future relative to the end of statement date. AFAIK there is nothing which prevents a user from reconciling a future event to the account. These appear in the debits and credits panels in the reconciliation window even if their transaction posted date is after the end of statement date so they can be checked for inclusion in the relevant reconciliation process along with the original transaction they correct - hopefully to the value recorded in the statement. David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Dale, I was referring specifically to the dates the bank puts on transactions included in the statement for a specific period but not necessarily the dates that may have been recorded by a user in GnuCash. The latter of course may be different and the reconciliation process deals with that. I disagree with you however about which date should be recorded as the *reconciliation date* for a split to the specific account you are reconciling for a transaction maked as 'y' (not 'c'). When you do a reconciliation you are confirming that the transactions in your books agree with the transactions in the statement up to the end date of the statement are correct in the amounts recorded and that the balances recorded by the bank and yourself at that date are in agreement. This is the date you are reconciled to not the date at which you entered the transaction into GnuCash or the date at which you posted the transaction (the date at which the event which causes the transaction to be recorded occurred). Both of these dates are already recorded in the Gnucash transaction data structure and recording them as the reconciliation date on a split does not really add any new information. David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
hi Geert The first was really about directConnect OFX imports, not something I am all that familiar with since banks here won't allow us access. Another user in the discussion around Bug 797668 which I initially raised had mentioned direct reconciliation in the import of OFX directly from the bank. I may have misunderstood Gunter's comment that that procedure was starting the reconcile procedure and automaticallly reconciling. I was trying to say tthat if the bank provided enough information that matched the GnuCash information, it may be possible to reconcile automatically but I think Gunter was actually referring to the marking of the transactions as cleared so it appeared checked when the reconcilaition was initiated. Agreed that the statement date is totally independent of the transaction date. The dates in a statement will all fall between the end date of the last statement +1 (the start date of the current statement) and the end date of the current statement as the statement dates are inclusive. The importers as far as I can tell so far (OFX and CSV) don't set the reconcile flag to 'y' only to 'c' and the reconcile date is set to TODAY in the importing process. This shouldn't affect the manual reconcilaition process though which should set the reconciliation date to the statement end date when the flag is set to 'y'. I am currently trawling through the code to satisfy myself that I understand fullywhat is happening and will update the documentation accordingly if the update i did last year is misleading. Davdi - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Frank Agreed. The other difficulty is that there is no control over a bank's particular implementation unless they are strictly adhering to a well defined standard and even then some countries adopt different standards. It is moot for me in any case since Australia's major banks don't allow directConnect server access except through selected software providers. if the bank process fails or does not supply the necessary required information I guess you would mark it as unreconciled but that assumes the user is gong to be able to do a manual reconciliation. david - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
David T, Christopher, Dale et al In accounting terms a reconciliation is always a confirmation of the details of the splits to an account against some external record independent of the particular set of books records are kept in. This is generally done in a set of contiguous periods over which that external record is available. A statement like a bank statement which is issued periodically is the most common example and probably the most systematic. (I have in the past had to reconcile a statement from a supplier of credit dealings against A/P and Payments for example and many similar processes for a business a process not necesarily as easily automated or defined as against an account but I don't think reconciliation in this wider sense is what we are dealing with here.) I don't see any problem with the reconcile status at present as implemented in the QIF, OFX imports or even the AQbanking import of transactions and balances, provided the bank accepts that record is a statement of the account on their part. With AQbanking and OFX directconnect import of records, the process. If the process of querying the bank server for records can provide a starting balance at the end of any past downloads of data, the transaction split details for the account and relevant details and the bank's record of the ending balance at the end of that group of transaction splits then it should be in principle be reconciled using an instance of the current procedure where the date entered for the transaction = reconcilation date of the split = end date of the statement=date at which reconciliation was carried out. In the more general case there are multiple relevant properties and dates associated with a reconciliation cuirrently recorded: *date entered* - a transaction property *date posted* - also a transaction property *reconciliation status* split property ["n","c","y" ] only the "y" indicates reconciliation. being cleared is different from being reconciled. *reconciliation date* - split property - currently set by the reconciliation process to the end date of the statement as the date to which that split is reconciled AFAIK. and some which are currently not recorded AFAIK but could be useful if maintained in a reconciliation history for the account as a list: *date of reconciliation* - date at which a reconciliation was carried out -limited use but may be of some use in tracking down errors *statement start date* *starting balance>* *statement end date>*. This would obviously need additional data structures, data file modifications, ie not short term. If we are going to try and verify the integrity of the account and reconciliation process we need to to > Looking this over, it seems to me that your goals could only be achieved > by adding a statement date data element to each transaction, which would > tie that transaction to a specific statement. David the problem with this is that reconciliation (and its parameters like reconciliation date and status) are the property of a particular group of splits to a particular account so any data elements that record whether a record is reconciled or not and to what statement period it is reconciled properly belong with the split where they are now. If one is recording the end date of the last reconciliation period and any associated balances which pertain to the whole group, these really should be properties of the account that was reconciled rather than a transaction which has links to two or more accounts and can be independently reconciled in each of those accounts. David Cousens - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
I was not aware that AQbanking does a reconcile on the fly. I also use OFX, CSV nad very occasionally QIF imports (but not from Quicken) but not that heavily any more. I think it would be useful to have this information about the reconcile marking process documented at least in the importing section of the help manual. There are sections on reconciliation in several sections of the guide and the help manual. I suspect it is covered but there isn't a nice summary. I don't know enough about how AQbanking works at the bank level, e.g. whether it only makes transactions available after all bank internal processes (clearing) have occurred as my bank hasn't implemented it and refuses to on security grounds (but it does allow MYOB and a number of other commercial packages direct server access but only on business accounts not personal accounts - no doubt for a hefty fee) but it is clearly regarded as the equivalent of a statement. In my manual OFX downloads for my credit card, the bank records transactions as pending in their web portal, which I have made, but are not yet cleared through VISA, until they get a clearnce from VISA. I can't include the pending transactions in either a CSV or OFX download which makes sense. The shortened times for electronic clearance between banks these days usually means that i have had no conflicts between downloads and statements for several years now unless I have had finger trouble in importing. On my Savings account I can't remember having had a transaction marked as pending since electronic clearing came in. I will put it on my to do list to find an appropraite places to put such a summary. I tried to rationalize the Guide recently by having a general section Ch4 on reconciliation and then pointing to the existing sections which were focussed on reconciling specific account types. It makes sense to me to store the last reconciliation date and the ending balance at that date in the account data then by comparison with calculations of the starting balance on the fly, there would be a good mechanism for detecting any altered transaction splits invalidating a previous reconciliation and alert the user. Even more useful perhaps than just the last reconciliation date and end balance would be a complete reconciliation history for each account but that introduces alot more complications for forward/backward compatability but it would improve the ability to verify account integrity and to locate when a change affecting the account integrity was introduced. By "fix" in this context are you referring to the exclusion of the future reconciliation dates from the starting balance sums or a manual or auto fix to the future reconciliation dates themselves. I am still trying to work out if an autofix is possible for the future reconciliation dates case. It may be possible from the transaction dates posted and dates entered for splits which have a future reconciliation date to identify a potentially valid reconciliation date if you were also able to construct a list of all reconciliation dates used by the account which was what i did manually i.e. suggest the earliest and latest reconciliation dates a user could choose to be consistent with the rest of the account data. The same approach may also be the basis of an internal check on the stored reconciliation data validity. David ----- 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
Re: [GNC-dev] Documentation flow; was: About 3.9 and reconciliation balances
Thanks Frank That was pretty much what i thought the situation would be. Perhaps we should add a note about the flow somewhere That is easily accessible to users in the documentation so that users have a better idea of where to look for up to date recent and rapidly changing information. I will setup a Wiki page detailing what I discovered about the effects of Chris's fix in 3.9 even though the plan is to drop it from 3.10 for the moment. Gunter Kamp seemed to have a related but slightly different issue associated with AQbanking. Banks here haven't generally allowed any direct server access other than downloads from their web portals so i have no familiarity with AQ banking David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
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 thing is to update the documentation with appropriate instructions and in the shorter term put this up on the wiki in the meantime. I don't know if it is legit or desirable to reference a wiki page from the documentation or even from within the program (in the warning popups for example) but this may be a temporary way to alert users and point users to a solution until an autofix procedure can be developed. I can start preparing a wiki page outlining the problem and how to do the manual fix to the XML file. I guess SQL users could always save their data to XML, do the fix and then reopen the fixed XML file and then resave to the database as a fix while it is fresh in my mind. David Cousens - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
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
Re: [GNC-dev] About 3.9 and reconciliation balances
A previous reconciliation on 31/12/2018 had had the statement date entered as 31/12/20 rather than 31/12/2018 which causes the entered date to be read as 31/12/2020 into GnuCash. I checked the entered dates on all transactions which had 2020-12-31 as the recociliation date verified these were all splits to the account I had been trying to reconcile and that the entered dates were consistent with a reconciliation statement end date of 2018-12-31 for a reconciliation carried out on 15/01/2019. Editing the XML data file and changing all reconciliation dates set at 2020-12-31 to 2018-12-31 The account now reconciles with the correct starting balance. David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Typical very old transaction that has had its reconciliation date altered but not by reconciling the period it is from (The date the transacion originally occurred and the weird date 202-12-31 and the reconciliation date for the other split of the transaction are highlighted. Only transaction splits to my PayPal account (guid d5918ab81d0a78a9b0b167f38f7e6bb3) have been affected. I haven't yet determined whether it is all or only some of the the splits to this account which have been altered. c081e40b43b03afbb16972d9e01d286a CURRENCY AUD * 2016-07-18 10:59:00 + * 2017-01-05 05:34:41 + Direct Debit 279234 PAYPAL AUSTRALIA 4QU229QXCL3ZC date-posted 2016-07-18 notes OFX ext. info: |Trans type:Generic debit 83954d093b9c8cbfc8f5ee5f4ef30067 y * 2020-12-31 13:59:59 + * 2000/100 2000/100 d5918ab81d0a78a9b0b167f38f7e6bb3 f5ad907bdae7fc58e365bde2c40a7e91 Direct Debit 279234 PAYPAL AUSTRALIA 4QU229QXCL3ZC y * 2016-07-31 13:59:59 + * -2000/100 -2000/100 fa0b7ad960e493b992a2dd374bbd1070 online_id D620002676419001NPA David - 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
Re: [GNC-dev] About 3.9 and reconciliation balances
Chris, 1. I am concerned that the "new method of calculating starting balances" introduced in GnuCash 3.9 may have a problem. I am still tracking down exactly what happened in my case. I do have a future reconciliation date on some transactions that had previously been imported in V 3.8. A preliminary look at the data file after it was first opened with 3.9 seems to indicate that v3.9 itself introduced those spurious reconciliation dates. At this stage it is not clear how these future reconciliation dates have been added. I reverted to v3.8 (after attempting to reconcile in 3.9 and getting a weird starting balance not in agreement with the previously reconciled closing balance) and I was able to get the correct starting balance and complete the reconciliation to the end of the next statement (I didn't actually apply it) but the difference was 0 and the reconciled balance agreed with the closing balance of the statement. I am in the process of chasing this up in the XML datafiles and my backups (last 30 days) which go back to before I changed from 3.8 to 3.9 to try and determine exactly when and how the spurious future reconciliation dates came about. It may have been a mistyping on my part while reconciling what is the target account of the splits from the account I am currently trying to reconcile. Why should the reconciliation dates of the splits that are to an account other than the one I am currently I am reconciling affect the process of reconciliation? From an accounting perspective my view is that it should not. Reconciliation of accounts should only be dependent upon the splits to the account being reconciled and the exrternal statement that it is being reconciled against, not the data associated with any other account. A more important question is how these spurious future reconciliation dates arise in the first place. Most likely as a result of mistyping the date during entry. *At this I would suggest reversing these changes to the starting balance calculation if possible in 3.10, abandoning 3.9 and reverting to 3.8 until 3.10 can be released. I think a more thorough examination of the cause of the problem it is trying to address and whether checks on the entered statement date and issuing a warning for the user to decide is not a better approach. Derek's is possibly the only user case where one might want to reconcile in advance 1. I fail to see why there is any necessity to restrict the statement date in any way. OK warn the user that their statement date is in the future with a popup, but if that is what they want to do why stop them. 2. I don't agree with imposing any random repair process. I think we need to identify firstly how and why this is ocurring and particularly why historical dates that are not associated with transactions in recent reconciliations are having their reconciliation dates altered (see below) by a relatively recent reconciliation processes. The reconciliation process should not be altering records of past reconciliations. Once that is identified and fixed then consider a repair process. * The problem is I have now found spurious 2020-12-31 reconciliation dates applied to transactions which were recorded and reconciled originally at the time 2015 -2017 in the Paypal account I have been trying to reconcile for 2019-2020 and these are also present in my back up files as at 22/03/2020 which were created when I was still using v3.8 ( I only keep 30 days of backups) so I can't go back further. Only the reconciliation dates on the Paypal account have been changed and reconciliation dates on other splits in the same transactions are still set at dates in the 2015-2017 range which indicates that it is a reconciliation process applied to the Paypal account which is causing the problem. AFAIK at this stage the spurious 31-12-2020 reconciliation date is only occurring in my Paypal account (Liability) and not any other accounts. I have established that I reconciled thePayPal account on 03/04/2020 in v3.8 (v 3.9 was installed on 06/04/2020 at 17:46:55AEST and I mark statements which have been reconciled by appending "_R" to the file name so the file modification times when I did the reconciliation) against a statement to 31/12/2019 which is when I could possibly have entered the 31/12/2020 date incorrectly if that was the cause. However the spurious reconciliation date of 31-12-2020 is present in transactions to the PayPal account in a backup file created 22/03/2020 so it is hard to explain as a result of a reconciliation which ocurred on 03/04/2020. The problem with a future reconciliation date being present was then not created by V3.9 and Chris Lam's mod only highlighted that it was already present. David Cousens - 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/mail
Re: [GNC-dev] QIF Import Suggestion
Alan Bugzilla (https://bugs.gnucash.org/) is just a web interface for filing information about a bug and is meant for users to report problems to the developers. You don't really know how to administer it and set it up to file a bug, but you do need to be a registered user on Bugzilla to file a bug (to reduce nuisance and prank filings etc). If you click the File a Bug button on the web page at the above link, it will take you to a login page which has a link to an account creation page if you are not already signed up. It is basically a form for entry to a database to fill out identifying which version of GnuCash and on what OS the problem occurred and what the problem is. Most of it is selecting options from dropdown menus and you can just copy your post in the User forum and paste it into the descriptionfield in the Bugzilla form. It is the primary interface developers work from in fixing GnuCash problems as bugs are addressed in a priority order depending on how severely they affect GnuCash operation. The developers are largely volunteers, often hard pushed for time so if things don't go into the system, there is little likelihood they will be fixed. David Cousens - 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
Re: [GNC-dev] Single User Installation location on Linux
Strange I or someone else must have changed the wiki after the previous discussion. It now has $HOME/opt as a recommended location and points out that it can be any directory the user chooses. David - 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
Re: [GNC-dev] Single User Installation location on Linux
John, These were previous mentionsof $HOME/.local. My emeory of things is getting a bit flawed these days. I don't think it was a rtecommendation as such. The original wiki before I modified it had $HOME/.local as the single user location http://gnucash.1415818.n4.nabble.com/GNC-dev-About-the-HOME-local-installation-prefix-tp4710196p4710237.html http://gnucash.1415818.n4.nabble.com/GNC-Building-v3-Wiki-entry-for-Ubuntu-tt4701508.html#a4701569 http://gnucash.1415818.n4.nabble.com/GNC-dev-About-the-HOME-local-installation-prefix-tp4710196p4710262.html The thread above seems to also conclude a $HOME/apps location or similar as a better alternative. i obviously didn't follow up and modify the wiki at the time. Will put it on the to do list this time. http://gnucash.1415818.n4.nabble.com/GNC-Uninstall-GC-tp4708376p4708497.html I couldn't find any earlier references. I will change the wiki to recommend using a directory under $HOME aka /home/. I will suggest using $HOME/apps but point out it can be any directory name the user chooses and can be a hidden directory if the user so wishes. I will also add some suggestions for alternative ways to include the executable in the PATH environment as well as a suggestion to include a launcher in the OS's menu system as per the distro's methods. David - 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
Re: [GNC-dev] Single User Installation location on Linux
Geert I had a short discussion about where to install for local use with John when I started updating the wiki a couple of years ago. At that time the user gnucash data files weren't in $HOME/.local/share/gnucash so there was no possible conflict at that time. The $HOME/.local/bin was added to PATH in my default user .profile supplied in Linux Mint which is executed by the command interpreter in login shells. It also adds $HOME/bin to the PATH and includes .bashrc if it exists., so it is a distro dependent addition and we can't assume it will have been added in all distributions. .profile <http://gnucash.1415818.n4.nabble.com/file/t375329/.profile> If $HOME/.local/bin or $HOME/bin is in the PATH and has a soft link in either location to the executable then just typing gnucash at the prompt in a terminal will start it (AFAIK as long as there isn't another link earlier in the PATH variable which gets activated first). My own practice is to create aliases which address the specific executable and locations when I have multiple versions installed or if the use is likely to be longer term create launchers for the specific version in the LM menu. > That will depend a bit on the history behind the choice for $HOME/.local > in > the first place. That was the main reason why I raised it here after Frank pointed it out in a comment on my reply to a user in the user forum. It may be the user data files can coexist happily in $HOME/.local/share along with the program data files as it is a single user installation. I built and installed 3.8 to $HOME/.local yesterday to check it out. make uninstall seems to have removed the files placed in $HOME/.local/share/gnucash in the install without affecting the user data files in the same location, but just leaves the trail of empty directories the files were in.The risk is in a user doing a manual uninstall of the program and accidentally deleting the user data files with custom reports, checks books etc. David Cousens David - 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
Re: [GNC-dev] Single User Installation location on Linux
Hi Frank,
I agree with the general point of using a directory under $HOME as the
installation point. What it is called is really up to the users preference.
$HOME/.local/bin seems to be included in PATH by default on Linux Mint. Not
sure if that is necessarily the case for other Linux distributions. I have
adopted using a simlink from $HOME/.local/bin to the executable in
$HOME//bin/gnucash if I have a local installation.
That has the advantage that the PATH variable doesn't become cluttered with
a lot of individual paths to other installed applications. Not all other
aprograms necessarily install cleanly in the $HOME/{\bin | \etc
| \lib | /include | \share} structure. I have some which have the structure
$HOME///{\bin | \etc | \lib | /include |
\share} which in time will hopefully become more consistent.
I personally only have a few apps I install for a single user, usually just
apps I am trying out. Most including GnuCash are installed system wide in
either /usr/local or /opt but we probably need to consider those users who
are either not comfortable with system installation or do not have the
privileges for system wide installation or easy access to those who do.
I do also install builds of maint and master branches locally but I use a
separate directory again under my home directory for any development
installations.
Possibly the best way to go in the wiki is to specify a general form like
in the syntax and point out that the user can subsitute
their choice for .
I am experimenting with a bash script to do the full install including
download of a selected version from a list of the current available versions
from SourceForge, extracting it and either a system wide to /usr/local or
/opt or a local install to a specified directory under $HOME. I would like
eventually to be able to query SourceForge for the list of available
versions but my bash skills are still too rudimentary. The install part of
the script is easy it is just setting up the option selection which is
proving a challenge
David Cousens
-
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
[GNC-dev] Single User Installation location on Linux
The wiki Building on Linux currently recommends doing a single user local installation to $HOME/.local. Frank Ellenberger pointed out to me in a thread (http://gnucash.1415818.n4.nabble.com/GNC-How-to-install-GnuCash-from-Source-for-Linux-tt4716225.html) on the User forum that this results in $HOME/.local/share containing both program and user configuration data in $HOME/.local/share/gnucash. The data seems to happily coexist, i.e. no folders or files from the program and configuration data seem to have the same name and make uninstall appears to leave program data in that location after uninstalling. The following is a list of the accounts in the location after an install to $HOME/.local. The files/folders marked with a * following them are the ones which were present in that location prior to installing GnuCash in $HOME/.local (my user config data from my normal installation running from in /usr/local). After an uninstall, the files seem to be deleted but the folders are not generally deleted so an uninstall of the program is not complete. $HOME/.local/share/gnucash*/accounts /books* /checks * /gtkbuilder /icons /jqplot /pixmaps /python /scm /translog * /ui* /accelerator-map * /expressions-2.0 * /qif-accounts-map * /saved-reports-2.8 * /saved-reports-2.8-backup * /stylesheets-2.0 * If I create a directory .apps under $HOME then GnuCash installs to it without any problem but no link from $HOME/.local/bin to the executable in $HOME/.apps is created by the installation and the user would have to create this this manually. Once this is done GnuCash seems to run fine from $HOME/.apps as a single user app. The question is do we need to change the recommendation for installing under $HOME/.local on the wiki and what should we change it to? If it is agreed this is necessary I will modify the wiki to suit. David Cousens - 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
Re: [GNC-dev] Using ending balance from OFX file as ending balance of reconcile?
Jean Can't rtemember if it was discussed or not but there are possibly good reasons for not using the ending balance of an OFX import as the starting balance for a reconciliation. 1. Depending on when the download is done, the bank may or may not have included all of its charges and interest whereas a statement is usually provided some time after the period of the statement and has all appropriate fees and charges and adjustments included up to the closing date of the statement. By providing a statement the bank is certifying this. 2. Reconciliation is the process of ensuring the accounts transaction record is in agreement with the bank's. The bank considers its records true and correct when it provides a statement of account that is certified to be so. 3. The starting balance of the next reconciliation has to be the ending balance of the previous reconciliation to ensure that no transactions are missed or extra transactions included in the period of the statement. Maybe the situation may become different if and when banks are prepared to declare their download OFX records are true and correct at the time of download. David Cousens. - 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
Re: [GNC-dev] Dependency graphs
They're pretty impressive Geert. I had them spread across 3x24 " monitors in GIMP to be able to see enough to start to make sense of them. David - 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
Re: [GNC-dev] Multiple mismatchs between e.g. gnucash-guide.xml and *-C.omf
Frank, I am coming across a similar problem in that I would link to be able to use olinks to cross reference between the Help Manual and the Tutorial and Concepts Guide as it seems the logical waty to do it. i will be/have shifted some materail from one to the other and now find it is linked within the same document with links whicxh get broken. Did you make any progress with implementing olinks. I didn't see an olinkdb.xml file anywhere so I have had a go at creating one but I am not sure where to create/find the target .db files for the help and guide. I would presume these should be created in the build file structure. I think I can see where to modify the xsltproc instructions in xmldocs.make in the section # ** Rules to make and install html documentation I would propose adding another target here to create the target.db files to the existing "convert-html:" , "copy-pics:" etc and add it to the list executed by " html:" before the convert-html i.e. olink-targets: which would run the xslt proc with --stringparam collect.xref.targets "only" rather than the flags that are in "convert-html:" target. I have little experience with xsl processing and even the make procedure for the docs so would appreciate any comments you or Geert might have. Are there any plans to move to DocBook5 in the future? Thanks David Cousens - 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
[GNC-dev] Guide Importing Chapter rewrite Doc Bug l;'797439
I am proposing the following outline for the Guide chapter on importing data from files: Importing Data into GnuCash Importing Transactions from Standardized Data Files (covers QIF,OFX, MT940,MT942, DTAUS etc ) QIF OFX/QFX MT940 MT942 DTAUS Importing CSV Format Data Chart of Accounts Export Format Importing Transaction Data Importing a Minimal CSV Data Set Importing GnuCash Export Format Multi-line Multi-split Data (GnuCash Export Format) Importing Minimal Multi-line Multisplit Data (minimal data to successfully import multisplit data) Importing Price Data Each section will include a sample data file with some examples of common transactions (transfers, income expenditure) + currency transaction + stock transaction and try to cover common problems encountered importing transactions data with screenshots of the windows. Some sections currently in Help re QIF, OFX etc may be better positioned here. In the Help manual section on importing transactions I tried to concentrate on describing the interfaces in detail rather than the process whereas the Guide sections I am intending to concentrate on the examples and process. I am not covering importing business data as there is already a section on that in the Business section of the guide, although I am open to suggestions. Any comments/suggestions welcome. David Cousens - 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
Re: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?
John, Is there perhaps a need to place maintenance limits on GnuCash release versions, i.e. at a specified time after release they become unsupported, as is bugs and all. This is more than likely what actually happens in practice given limited skilled developer time. As bug reports are often tied to a specific version, bugs could then be removed from bugzilla when the version they apply to becomes unsupported. Most bugs are not show stoppers and those that are or are particularly inconvenient are usually fixed fairly quickly after release. Enhancement requests could possibly have a longer lifetime but perhaps there is a need for expiry on those as well. E.g. if they didn't make it into the next major release and you really need that feature you raise the issue again (or work on it yourself). David Cousens - 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
Re: [GNC-dev] Gnucash built from git doesn't start
John, I am curious as to what problems you have encountered installing to /usr/local and on what Linux distributions? I have never had any problem installing there in Linux Mint 17, 18, 19 which presumably also includes the Ubuntu and Debian systems they are derived from but don't know about other distributions. According to the Linux File Heirarchy standard this is where user software built from source should be installed. The "sudo make install" currently installs the libraries, share and config files in the expected locations as follows: /usr/local/bin/gnucash main application /usr/local/etc/gnucash/environment /usr/local/include/gnucash gnucash heaader files /usr/local/lib/gnucashgnucash libraries /usr/local/lib a few libraries associated with libgnc-backend, libgnc-core-utils, libgnc-gnome, libgnc-module and libgwengui-gtk3 /usr/share/gnucash Apart from requiring sudo privileges I have never encountered any problems installing there since I started using GnuCash in 2010. David ----- 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
Re: [GNC-dev] Mouse usage in Gnucash
Frank, I think I have worked out how to make the keycap keysym and mousebutton tags bold without having to use the tags by creating mousebutton.xsl and keycap.xsl and having them included in general-customisation .xsl in the same way the guimenu.xsl bolded the menu items. I will go through and remove the emphasis tags from those elements where I have used them excessively and then check if it works OK. Agree about adding a common section to both docs with some interface guidlines to also translate mouse buttons to touchpad and simple touch screen conventions David - 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
Re: [GNC-dev] Mouse usage in Gnucash
Hi Frank, Sorry I am referrring to the glossary currently in the guide. Ok found the 1.79.2/html/glossary.xsl but it is beyond my current understanding of xsl processing to modify it. I am slowly getting the idea but don't want to invest the time at tis point to get up to speed. I'll add the appropriate references to the gnome hig in the gnc-docbookx.dtd as you suggested. David - 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
Re: [GNC-dev] Master now requires C++17
John, Defaults on Linux Mint 19.2 are: gcc 7.4.0 (gcc 8.3.0 is available for Ubuntu 18.04 (Bionic) at https://packages.ubuntu.com/bionic/gcc-8) clang6.0.0 libboost 1.65.1 (it will likely be patched as it is Ubuntu 18.04 based. There is also a ppa where libboost 1.67 is available for 18.04 https://asciinema.org/a/199344 if you are not averse to installing from non distro resources.) David - 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
Re: [GNC-dev] Mouse usage in Gnucash
Thanks Tommy, The gnome developers guide is a useful read in any case apart from the mouse specific issues. They seem to settle on the primary and secondary descriptions in one place and then use the left-click right-click etc, particularly in the glossary (https://developer.gnome.org/gdp-style-guide/2.32/gdp-style-guide.html#gnome-glossary-user-actions) description of user actions. It may be useful to link to this from the wiki on udpdating the documentation( see below). Perhaps a glossary may be a useful place to eventually include references/crossreferences to alternate actions. The current docbook glossary is not terribly useful for html documents as it simply displays a popup with the glossary term in it rather than the definition part of the glossary entry which would be really useful. That behavior could be altered by using some custon xslt processing in the build but I don't have any expertise in that as yet. At present the glossary exists only in the guide and not the help manual. There is a way of making a common glossary available in both but it will require some alteration of the build structure. I am avoiding that at the moment because I think it is more important to update the documentation in a few areas where there were new features in V3 and I don't have the expertise in the cmake and xslt processing to do it easily at the moment. This section is a pretty good guide to usage in developments and the organization of GTK3 https://developer.gnome.org/hig-book/unstable/input-mouse.html.en particularly the table of mouse and keyboard equivalents. The GDK reference manual refers to Button 1,2,3 with 1 Left 2 Middle and 3 Right but that is more related to usage in coding than in user documentation. There is no style guide in the Gnome documentation guide sense but there is the wiki on updating documentation (https://wiki.gnucash.org/wiki/Documentation_Update_Instructions) but it doesn't refer to mouse interaction descrptions. My inclination is to stay with left click, right click descriptions as for a two button mouse for the moment. It is probably more important to be consistent rather than totally compliant with being as general as possible. I think some general reference to the GTK3 input-mouse.html document would be useful as all the intefaces are based on it as well as https://developer.gnome.org/hig/stable/pointer-and-touch-input.html.en bu that is problematical as these are external references. If it is desired to change this a global search and replace can always be used and much of the current documentation uses a left click, right click convention David - 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
Re: [GNC-dev] Mouse usage in Gnucash
Thanks John, I agree totally. I am trying to settle on something which might be intelligible or at least easily translatable to users on other OSs and devices. Frank raised the issue with me while reviewing changes to the help manual importing section. I tried what he suggested out but my view on the end result is that it ends up being unintelligible to everybody and I may yet revert it. I am not too concerned about fairly experienced users (they will figure it out) but the novice who comes in without too much experience of other OSs and computers is the real target - the one who gets hung up if the description is not exactly the way the box in front of him operates. They are becoming rarer beasts these days once they have grandkids to educate them properly. I personally am happy with the left click/tap and right click/tap notation and then let users translate that as required for their specific equipment/OS as necessary. My son is a leftie and he has never really had a problem translating automatically from the RH world unless the devices were physically right handed. The touchpads on my laptop and tablet with a touchscreen all respond to tap/s on either side of the touchpad or on the screen as expected so the click/tap may be the way to go. I don't use tablets too much so I'm not too au fait with the finer points of gestures in any case. I just blunder my way through. David - 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
[GNC-dev] Mouse usage in Gnucash
Do we by any chance have some sort of standard description of mouse usage in GNuCash on the various OS. I am updating documentation. Docbooks has tags for description of mouse operations. With configurable mouses for LH or RH operation terms like Left Click and Right Click start to become ambiguous. DocBooks has tags for . In a review of some recent changes Frank suggested using Button1, Button2 and Button 3 rather than Left, Middle and Right to avoid the LH/RH mouse conundrum. I haven't been able to find anything in the documentation re input devices but I could have missed it Two of my mice have 6 buttons and two scroll wheels (basic config is a 2 button + central scroll/button) and another only has 2 buttons and a single scroll wheel/button. Linux Mint can configure that for LH operation, emulation of a centre button by pressing both buttons together, scrolling reversal and double click timeout and I presume most OSs will have something similar. Then we go to Macs and we have single buttons and magic mice to contend with. Then there are tablets and touchpads and gestures. GTK3 seems to support a wide range https://developer.gnome.org/gtk3/stable/chap-input-handling.html and does interpret the scroll wheel appropriately on my mice but the wheel button inserts "another" each time it is pressed while editing a transaction in a register - not too useful. It is clearly far too onerous to describe all possible mice/input variations. My own preference would to perhaps settle on a fairly common 2 button RH basic mouse and keyboard configuration and describe operations in terms of that. Perhaps then offer in a wiki section some translations from this configuration to other configurations like track pads that could be populated by users. I think Left (Centre) Right for a RH mouse is likely to be far less confusing to translate than a "Button1 Button2, Button3 where it is totally ambiguous whether the mouse is LH RH or upside down. Any feedback would be appreciated. David - 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
Re: [GNC-dev] Build fail on Linux Mint 19.2
Geert, gnucash-3.7 is the top levl directory (extracted from the traball) and it has gnucash, libgnucash bindings etc. in it as well as the build directory which is why the ../gnucash to get to the source directory from the build directory. I have been using that configuration for building v3.0, 3.1,3.2,3.3,3.4, 3.5and 3.6 without any problem. $cmake _DCMAKE_INSTALL_PREFIX=$HOME/.local -DWITH_PYTHON=yes .. worked OK . My bad. Thanks David - 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
Re: [GNC-dev] Build fail on Linux Mint 19.2
Hi John, Changing to CMAKE_INSTALL_PREFIX=$HOME/.local didn't change anything - same errors. I have been installing to /usr/local using cmake since it was introduced without any problems since it was introduced as the build configure system. I have both the libgtk2 and libgtk-3 packages and development headers installed (gtk2 for other software) ii libgtk-3-0:amd64 3.22.30-1ubuntu4 amd64GTK+ graphical user interface library ii libgtk-3-bin 3.22.30-1ubuntu4 amd64programs for the GTK+ graphical user interface library ii libgtk-3-common 3.22.30-1ubuntu4 all common files for the GTK+ graphical user interface library ii libgtk-3-dev:amd64 3.22.30-1ubuntu4 amd64development files for the GTK+ library Is the SWIG patch for building on Windows useful in Linux Mint? David - 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
[GNC-dev] Build fail on Linux Mint 19.2
2.99.3-2 amd64CLI binding for the GLib library of C routines ii libglib3.0-cil-dev 2.99.3-2 amd64CLI binding for the GLib utility library 2.12 ii libglibmm-2.4-1v5:amd64 2.56.0-1 amd64C++ wrapper for the GLib toolkit (shared libraries) ii libglibmm-2.4-dev:amd64 2.56.0-1 amd64C++ wrapper for the GLib toolkit (development files) The cmake log and error log fromgnucash-3.7/build/CMakefiles are attached: CMakeOutput.log <http://gnucash.1415818.n4.nabble.com/file/t375329/CMakeOutput.log> CMakeError.log <http://gnucash.1415818.n4.nabble.com/file/t375329/CMakeError.log> Installed swig files: david@Mintie:~$ dpkg -l | grep swig ii swig 3.0.12-1 amd64Generate scripting interfaces to C/C++ code ii swig3.0 3.0.12-1 amd64Generate scripting interfaces to C/C++ code david@Mintie:~$ Installed guile packages: david@Mintie:~$ dpkg -l |grep guile ii guile-2.0 2.0.13+1-5ubuntu0.1amd64GNU extension language and Scheme interpreter ii guile-2.0-dev 2.0.13+1-5ubuntu0.1amd64Development files for Guile 2.0 ii guile-2.0-libs:amd64 2.0.13+1-5ubuntu0.1amd64Core Guile libraries david@Mintie:~$ Installed gdk packages david@Mintie:~$ dpkg -l | grep gdk ii gir1.2-gdkpixbuf-2.0:amd64 2.36.11-2 amd64GDK Pixbuf library - GObject-Introspection ii libgdk-pixbuf2.0-0:amd64 2.36.11-2 amd64GDK Pixbuf library ii libgdk-pixbuf2.0-bin 2.36.11-2 amd64GDK Pixbuf library (thumbnailer) ii libgdk-pixbuf2.0-common 2.36.11-2 all GDK Pixbuf library - data files ii libgdk-pixbuf2.0-dev 2.36.11-2 amd64GDK Pixbuf library (development files) ii libgdk3.0-cil 2.99.3-2 amd64CLI binding for GDK 3 ii libgdk3.0-cil-dev - 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
Re: [GNC-dev] Import Main Matcher
Bob, Any feedback is welcome. John Ralls has suggested that the right place for documentation of how the code works is in Doxygen comments in the code itself and I agree with him there. There is a design document in the code which I may be able to add to. For the user documentmation I will be trying to restrict it to what the code does although I will try and add some info on things like the hard coded limits used for some parts of the search for matching transactions as that can be useful to users. Just crossreferencing information between the help manual and Tutorial guide may also prove useful (e.g. the preference settings for the import matcher crossreferenced from the help manual. Could you use please reply all so that your reply is also copied to the mailing list when replying to messages from the list David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Problem building master branch
Hi John, I did do a fresh pull and fast forward. I also delete the contents of the build directory whenever I checkout a different branch before building and then rerun cmake and did for this one. I was getting the same problem when I tried to build my branch off the master so I went back to see if the master would build. Both had the same errors. I checked out the maint branch and built it with no problems. I noticed that Christopher Lam had modified a few of the Cmake files when I accidentally rebased on the maint branch yesterday so it may be a hangover from that that the git reflog somehow didn't fix. I'll try and track down exactly where the problem is occurring in the cmake files David - 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
Re: [GNC-dev] Import Main Matcher
Frank, One difficulty I have is in separating the interface description from the operational use of it in the case of the import matcher and the import process generally. Geert did a good job of incorporating the essentials in the popup help dialog in the interface and making it largely self documented, that it becomes almost superfluous to describe the interface separately, but there are always those to whom the help button is invisible. I will give it a go though. David - 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
[GNC-dev] Problem building master branch
Hi, I'm getting an error running make while building the master branch. It seems to be a problem loading gnucash/engine/gnc-numeric, which doesn't exist, but libgnucash/engine/gnc-numeric does exist in the sources. maybe primitive-load-path is not set correctly ? Make output where the error occurs is given below. Any suggestions? [ 32%] Built target scm-engine-0 Scanning dependencies of target scm-engine-1 [ 32%] Generating ../../lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/commodity-table.go wrote `/home/david/GnucashDevelopment/Repository/build-make/lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/commodity-table.go' [ 32%] Generating ../../lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/engine-interface.go wrote `/home/david/GnucashDevelopment/Repository/build-make/lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/engine-interface.go' [ 32%] Generating ../../lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/engine-utilities.go Backtrace: In ice-9/eval-string.scm: 44: 19 [read-and-eval # #:lang ...] 37: 18 [lp (use-modules (gnucash engine))] In ice-9/eval.scm: 505: 17 [# (use-modules #)] In ice-9/psyntax.scm: 1106: 16 [expand-top-sequence ((use-modules (gnucash engine))) () ...] 989: 15 [scan ((use-modules (gnucash engine))) () ...] 279: 14 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...] In ice-9/boot-9.scm: 3589: 13 [process-use-modules (((gnucash engine)))] 705: 12 [map # ((#))] 3590: 11 [# (#)] 2867: 10 [resolve-interface (gnucash engine) #:select ...] 2792: 9 [# # ...] 3068: 8 [try-module-autoload (gnucash engine) #f] 2404: 7 [save-module-excursion #] 3088: 6 [#] In unknown file: ?: 5 [primitive-load-path "gnucash/engine" ...] In engine.scm: 118: 4 [#] In ice-9/boot-9.scm: 1727: 3 [%start-stack load-stack ...] 1732: 2 [#] In unknown file: ?: 1 [primitive-load-path "gnucash/engine/gnc-numeric"] In ice-9/boot-9.scm: 109: 0 [# misc-error ...] ice-9/boot-9.scm:109:20: In procedure #: ice-9/boot-9.scm:109:20: In procedure primitive-load-path: Unable to find file "gnucash/engine/gnc-numeric" in load path libgnucash/engine/CMakeFiles/scm-engine-1.dir/build.make:80: recipe for target 'lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/engine-utilities.go' failed make[2]: *** [lib/x86_64-linux-gnu/guile/2.0/site-ccache/gnucash/engine/engine-utilities.go] Error 1 CMakeFiles/Makefile2:5301: recipe for target 'libgnucash/engine/CMakeFiles/scm-engine-1.dir/all' failed make[1]: *** [libgnucash/engine/CMakeFiles/scm-engine-1.dir/all] Error 2 Makefile:162: recipe for target 'all' failed make: *** [all] Error 2 David Cousens - 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
Re: [GNC-dev] Import Main Matcher
David, I also agree that the guide is the most logical place to place most of the detail for the Importing operations. However the same information is currently largely duplicated in the transaction operations section of the help manual including some recent updates re the importer and matcher. This may have resulted from the rearrangement you had in progress. I have recently updated some information in the Help manual section not realizing the same section was also in the guide. I would propose that we delete the section on importing in the help manual transaction operations and simply replace it with a cross reference to the Ch3 section on importing data in the guide and consolidate the current information into the guide there. If everyone is happy with that I can start that process. David Cousens - 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
Re: [GNC-dev] Import Main Matcher
Frank, I might also have to look at the recent additions to the Help manual and see if they are not better in the guide rather than the help manual. David T pointed me to the right place in the guide in another post. Agreed on the wiki. In addition to the information which might be useful to users, I have mapped out some the code linkages between the backend and the gui (currently in flow charts in YeD) which may be more useful to those new to the code. As John suggested I wil try and incorporate some of that in Doxygen comments in the code. David - 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
Re: [GNC-dev] Import Main Matcher
Hi John, Point taken on the documenting the how in the code and what it does in the docs. I have a slight familiarity with Doxygen but no great expertise but there is one way to change that. I'll ty and keep any Help and Tutorial description as general as I can while trying to provide something that will be useful to a user. David T has suggested Ch3 of the Tutorial and Concepts Guide as a possible home. David - 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
[GNC-dev] Import Main Matcher
At present the transaction importing documentation in the Help manual has no full description of how the import main matcher goes about the process of searching for and matching an imported transaction to an existing transaction or how it assigns a transfer account using the original mapping process or the more recent Bayesian approach. I am in the process of going through the code at present for my own edification and could create an expanded description of these processes in their current state either for inclusion in the Help manual or as a Wiki page. My concern is that a detailed explanantion in the importing transaction section of the help manual may make that section too long winded. If that is not a significant issue, that would be my personal preference. Does anyone have any strong preferences as to which is the better option ? David Cousens - 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
[GNC-dev] Proposed change of "U+R" and "R" in the Import main matcher.
I have raised bugs in the code(https://bugs.gnucash.org/show_bug.cgi?id=797338) and documentation (https://bugs.gnucash.org/show_bug.cgi?id=797337) proposing changing the "U+R" and "R" tags in the import main matcher to "U+C" and "C" where the curent use of R refers to the term reconciliation. The use of the term reconciliation in this context may cause some confusion with the reconciliation process of checking transactions for a period against an external statement, particularly for new users. The import matcher does not assign a "reconciled" status to an imported transaction but does set it as "c" cleared. You would not normally be importing transactions in which the splits to the account being imported to are already reconciled, i.e. marked "y" in a register however this might occur if you are importing records separately to a credit and a bank account where there are transfers between them (credit card payments). In this case the importer would flag the record not to be imported where there is an exact match to an existing transaction. AFAIK there is no checking of the reconciliation status of the existing transaction in GnuCash in the matching process but I may not yet have dug deeply enough. In a discussion with John Ralls and Frank Ellenberger over other changes to the import matcher documentation, I initially proposed "U+M" and "M". John felt "U+C" and "C were more indicative and clearer. I am raising this here to canvas a wider audience before making the changes. Please comment here preferrably (or in the bug comments) if you have any objections/support to the proposed change . David Cousens - 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
Re: [GNC-dev] A non-techie in need of help
Ellen, The cure for this is usually to use File->Open from the menu, navigate to where your data file is located, i.e. your Desktop,and open the file from the dialog. If you then save it once GnuCash is open.Hopefully Gnucash then will remember the location next time it is opened. The other way is to navigate to the data file in the File Explorer, right click and the use the Open with option to select GnuCash to open it. Once you have opened it either of these ways GnuCash should remember the correct location. If not it is something more specific then come back to the list. David Cousens On Tue, 2019-07-30 at 23:23 -0400, Ellen S. Dunlap wrote: > I'm a long-time satisfied Gnucash user, but have hit a technical snag that > is far beyond my ability to understand or remediate. > > I am using Gnucash 3.5+ (2019-03-30) and recently upgraded my Win10Pro to > version 1903. After the upgrade, when I open Gnucash I get a popup telling > me my current Gnucash file "could not be found. The file is in the history > list; do you want to remove it? Yes/No." I've tried yes and no, but seem > to be getting nowhere. > > I keep my Gnucash files on my desktop (and also backup to the cloud), and > when I open the desktop folder I see that the most recent Gnucash > transactions aren't there with the earlier sessions. > > Can some nice person on this list walk me (gently) through the proper fix? > Thanks. > > Grandma Ellen > ___ > 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] [GNC] Miscalculation in cashflow reports
Adrien, Geert, Frank Happened to have my accounting textbook handy this morning. The direct and indirect methods differ only in the way they calculate the cash flows from operating activities. The IFRS encourages the use of the direct method but does not exclude the indirect method. The following are from the Australian 5th edition of Horngren et al (http://pearson.com.au/products/M-N-Nobles-Mattison-Matsumura-Best-Frase/M-N-Nobles-Tracie-et-al/Horngren-s-Financial-Accounting/9781486021079?R=9781486021079 link is for current edition - diagrams form my copy of 5th edition). which is from the relevant Australian AASB107 standard which is adopted almost directly from the IFRS IAS 7 but does not permit use of the indirect method in Australia. The FASB in the US encourages use of the direct method but does not bar use of the indirect method (https://www.fasb.org/summary/stsum95.shtml). These are of course for accrual accounting and assume use of the conventional structuring of the account tree for a business for Current and Non-Current Assets and Liabilities. The outlines of the methods are attached Horgren_CashFlow_direct.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_direct.png> Horgren_CashFlow_indirect.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_indirect.png> and a simple sample Horgren_CashFlow_Sample.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_Sample.png> There recommended calculations for the Operating Section start from the Income Statement (bold items should be line items in the Income Statement) Receipts: >From Customers = *Sales Revenue* + Decrease in A/R - Increase in A/R >From Interest =*Interest Revenue* + Decrease in interest Receivable -Increase in Interest Receivable >From Dividends =*Dividend Revenue* + Decrease in Dividends Receivable -Increase in Dividends Receivable Payments: For inventory = *COGS* +Increase in Inventory _Decreas in Inventory + Decrease in A/P - Increase in A/P Other items = *Operating Expenses* +Increase in PrePaid Expenses - Decrease in PrePaid Expenses +Decrease in Accrued Liablities - INcrease in Accrued Liabilities to Employees =* Salary Expense* + Decrease in Salary/Wages Payable - Increase in Salary/Wages Payable For Interest = *Interest Expense* - Decrease in Interest Payable + Increase in Interest Payable For Income tax = *IncomeTax Expense* + Decrease in Income tax Payable - Increase in Income tax Payable. The Investing Activities Section is calculated as follows: Horgren_CashFlow_Investing.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_Investing.png> and the Financing calculations Horgren_CashFlow_Financing.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_Financing.png> the toals from each section are then summed to give the nett increase or decrease in Cash The cash balance from the Balance Sheet at the start of the period is added from this and should equal the cash balance from the Balance Sheet at the end of the period. There are also calculation methods for operating flows for the indirect method. The other sections are the same Horgren_CashFlow_Operating_indirect.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_Operating_indirect.png> sample presentation for the indirect method is Horgren_CashFlow_Sample_indirect.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Horgren_CashFlow_Sample_indirect.png> The report calculation under DRS21 as describe in the reference Frank provided for Germany does not appear to be conceptually different from the indirect method but has specific references to line items in the formats of other reports under DRS21 David Cousens - 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
Re: [GNC-dev] [off-topic] Re: Adding module to make GnuCash more valuable
Rosi, I think you really need to consider approaching a commercial software developer. Software is available with this functionality, maybe not in the form you propose, but there are commercial solutions out there: https://www.linbis.com https://lp.descartes.com/aljex-c-v1 https://www.logitudeworld.com https://allotrac.com.au http://smartfreight.com https://www.magaya.com It is not that what you propose may not be useful or meet a need in the market for free software, but that the development team for GnuCash is largely part time, have other jobs, retired etc. There are many core issues in GnuCash which need addressing to keep it viable with the functionality it currently has and barely enough people with the expertise and experience necessary to do that let alone undertake a major development project on top of that. Your comment: "Tell me if I'm wrong: the biggest problem software or web developers meet is the proper definition of the processes they have to implement. Projects are assigned by owners and managers, who are focused on different things - business flow and not the actual operations flow. " pretty well explains the need for a systems analysis team to engage with the FF industry in researching and defining those processes to develop the appropriate digital solutions, particularly when coping with international operations where legal jurisdictional problems can be complex. Gnucash might have individuals with the necessary systems analysis capability but they are most likely already committed. GnuCash is doable because the core of accounting is well developed and doesn't change much and has well developed international standards that most countries are pretty close to even if the haven't adopted those standards and GnuCash addresses that core requirement. It doesn't tackle customisation for individual requirements except by remaining flexible enough that those requirements could be met outside GnuCash. The other problem you mention is "interest". If one of the GnuCash contributors was sufficiently interested, generally because they are involved in the industry, you might strike it lucky. There is certainly no harm in canvassing the forum to see if that interest does exist. It may not necessarily exist. "accounting software is made to do the _book-keeping_" Accounting software is designed to do the *financial* bookkeeping i.e. track where they money goes to and comes from. It is not designed to track the location of goods, via a variety of shipping methods and routes, their departure and arrival and whether payment has or has not been made and whether their release should ro should not be authorized. That requires custom purpose made software with appropriate authorization methodologies incorporated into it. Gnucash has no methodology for external notification that a payment has been received which is about the only part of the operations you have described which falls within the accounting functionality of GnuCash. With a database backend version one could externally query the GnuCash database to obtain such verification but that would require a consistent defined methodology for ensuring tagging the payments recorded into GnuCash with references which can be tracked to the appropriate B/L. Good luck with getting banks to necessarily incorporate the additional information you need in their records. As others have commented I would think what you describe would be best implemented as an external program which can communicate the requisite financial information to GnuCash rather than within GnuCash itself. It is not the value of what you propose that we disgaree with in saying it is out of scope, but the capacity to implement what you propose with the existing available resouces. David Cousens - 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
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Geert, Agree with all the points you and david Carlson made. I had expected and guessed that the GnuCashbuild configured its search directories for resources from the cmake install prefix, but hadn't actually checked it out to be sure. The problem as I see it is recommending a setup for a novice or inexperienced user new to building and installing who may or may not have admin privileges to use that will allow them to install and uninstall fairly easily even when they no longer have the build directory and access to the make uninstall. Even with a little bit of development experience you can usually work it out for yourself. A user who is primarily interested in just using Gnucash and doesn't want to know about the nitty gritty of development per se but wants to be using the most up to date version, on the other hand, will get frustrated if every time he has to update, he has to figure out what went where and how to get rid of it. I'll rework the Wiki page to use a non hidden directory with a gnucash specific subdirectory as an install point in the example rather than $HOME/.local and just add notes to the effect that this directory can be hidden if desired by prefixing it with a dot. Then a simple rm -rf can be used easily. I'll also add some notes about setting up aliases to start it up. That should cover the user new to building from source. Then anyone who wants a more sophisticated setup can roll their own. cheers David Cousens - 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
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Colin There is no reason why the install directory can't just be an ordinary directory. There is no real reason for it to be hidden. It is what I use if I do do a local install. The only possible advantage is that if you can hide the directory it doesn't clutter the view of files when you won't be looking at program files the majority of the time even though you will be using them David - 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
Re: [GNC-dev] About the "$HOME/.local" installation prefix
John, Geert et al I have not been able to find any references on user directory organization apart from the XDG (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). There was one comment in this link (https://itsfoss.com/install-software-from-source-code/) which suggests that software installed in /opt from source expects to find its resources in directories relative to a package parent directory in /opt. and that this is why simlinks are used from/usr/bin or /usr/local/bin to the executable in /opt/ where the application stores its resources relative to /opt/. This seems to be how LibreOffice is installed on Linux Mint for example. I haven't had gnucash installed in /opt for quite a while now (or $HOME/.local) but I remember noticing that the resources for/opt were under a package directory. If the same situation (i.e. the ability to find program resources in a relative directory structure) applies for the installation in a user directory rather than installing directly under $HOME/.local we could recommend installing to a subdirectory of this location specifically for program installations and in turn create a directory under that for gnucash which would contain the executable and its resources. This would then facilitate easy removal of the package from a users home directory by simply deleting the package level directory to simplify things for inexperienced users. The above seems to be the case as I install development builds to an install subdirectory which is a subdirectory of a main directory which contains my gnucash sources and separate build directories for make and ninja etc and I have never detected that starting gnucash from the .../install/bin/gnucash executable has accessed resouces for production builds which I have installed in /usr/local. Can't be definitive about that but it has included changes to gnucash library files which appeared in the executable which wouldn't be the case if it was picking up libraries from the system installation. I guess this was the munge of the file locations that occurs with cmake for /opt and $HOME/.local type installations you referred to in an earlier post compared with installation in a system location. I.e. we recommend using cmake commands as follows for inexperienced or users who don't have admin privileges rather than simply installing directly under $HOME/.local which already has a gnucash directory for GnuCash user preferences. cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/programs/gnucash If you think this is a better idea (or there is another more general alternative I can update the Wiki build instructions to reflect this. The user could then create an alias in the bashrc file to access the executable and/or add it to their launcher etc. David Cousens - 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
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Hi John, It was because of a number of posts in the forum, not sure whether DEV or USER around the time I reworked the pages which suggested $HOME/.local for single user local installations of GnuCash . I think it may also have been specified the previous Wiki page I started from as well. At the time I could not find any better suggestions so I left it in place. My own preference has been to install in /usr/local or /opt system wide for production. If you use make uninstall from the build directory it seems to uninstall correctly from $HOME/.local as long as the manifest still exists as the paths to each file installed are specified If I do a local temporary install, I personally install in a subdirectory of my home directory and add the relevant search paths to the front of the PATH environment variable . You of course have the problem with the order in PATH as to whether you search $HOME directories before or after system installed paths if you have multiple copies of different versions. Ideally in that case you could invoke a startup script which setup the PATH variable depending on which version you are starting up and where its resouces are located. I have used /opt and /usr/local for different versions but the same problem with ordering the search order in PATH arises. Python installs what it calls site-packages under $HOME/.local which seem to be user specific but most of the other data I find in the directory is in $HOME/.local/share which seems to be mainly user specific data for various packages. The Linux File Heirarchy gives no real guidance for the structure of a users home directory apart from a reference to XDG and GLib conventions ( can't find any reference): https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html One stackexchange article suggested duplicating sections of the FHS under $HOME which seems a bit extreme. If I did that I would be inclined to have a specific directory under $HOME with the /bin, /etc, /lib /share directories under it. I have an Applications directory for that purpose usually with a package sub directory under that which contains the above directories. For the little development work on GnuCash I do I have a separate structure again under my home directory which has an install subdirectory which I install to. I have often wondered whether I am actually getting to the correct libraries by setting up the PATH variable (particularly if I forget to set it up). Then there is unsetting PATH when you want to go back to production work. Perhaps it is worth investigating the update-alternatives command used when several python versions are installed, e.g. https://askubuntu.com/questions/315646/update-java-alternatives-vs-update-alternatives-config-java. perhaps using this in startup scripts. Here the installed files are labelled with the version number and selected by setting a master and slave symbolic link groups which are setup with the "update-alternatives --set name path" command. Not sure what is the best location and structure for general users for a local installation though. I would be inclined to go for a directory labelled with a package name and version number with its own /bin, /etc, /lib and /share directories and then prepend these to the PATH. David Cousens ----- 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
Re: [GNC-dev] Bug796872 Multiple selection feature in import matcher
Thanks John, I took the fresh fork route. There should be a pull request for the files for the Multiple selection waiting for you. I'll go through the commands though to mprove my education. David - 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
Re: [GNC-dev] Bug796872 Multiple selection feature in import matcher
And the wrong bug report again again. I think the original was possibly closed before moving from the original bugzilla.org version. My only excuse is I was getting over a trip to Singapore and an overnight flight back yesterday. For some reason the changes in the commits https://github.com/Gnucash/gnucash/commit/01339a782c91a8d931cc9d7462ddce19afc60635 and https://github.com/Gnucash/gnucash/commit/cae8ecde8f9ddd615ff47c783ce8136395bd71a9 don't seem to have made it into v 3.3 on or if they did they didn't have the correct files. Due to my inexperience with git and github at the time you had to fix up a pull request from my github repository so that may have caused the problem. To get the multiple selection to work for myself, I have been patching 3.2, 3.3, 3.4 and 3.5 after downloading the sources before building. The version of import-main-matcher.c and dialog-import.glade which were in 3.2, 3.3,3.4 and 3.5 didn't contain the changes (file size of import-main-matcher.c in the gnucash-3..tar.bz2 in each case was 37.2kB for 3.5, 37.2kB for 3.4, 35.2kB for 3.3, 35.2kB for 3.2 for example, and my modified version of that file wass 43.8kB. I had the original source archives I downloaded for each version and have just freshly unpacked them to check that the code changes are not in the files.) I rebuilt 3.5 today with the modified files after adding in another patch to replace gtk_menu_popup with gtk_menu_popup_at_pointer to eliminate a warning coming up about deprecation of gtk_menu_popup and it is all working OK. I am inclined to clear out my github repository and my local repository copy on my computer and refork from GnuCash/gnucash to remove any consequences of my previous inexperience using git and github. I have and will retain separate copies of the altered files of course. If I then create a new feature branch off the maint branch and copy the altered files into that, push it to my repository and then create a new pull request, you should then get the right files which should fix things for the next release. If anyone wants to incorporate it before then I can send them copies of the patched files. David - 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
Re: [GNC-dev] Bug796872 Multiple selection feature in import matcher
Sorry John, I had the wrong bug number it should have been 796874 for the multiple selection mods. I have replaced a call to gtk_menu_popup with gtk_menu_popup_at_pointer in import-main-matcher.c but have yet to test it out. Looks like it will be a straightforward dropin for the deprecated call which popped a menu up at the pointer. David - 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
[GNC-dev] Bug796872 Multiple selection feature in import matcher
Hi John, I noticed from Jeff Albrecht's post in the User forum yesterday that the mods to the import-main-matcher to implement assignment of a transfer account to multiple transaction(-feature request Bug 796872) didn't make it into v3.5 although the corresponding documentation changes are now in the current document set. I originally made those changes in the master branch rather than the maint branch as it was a new feature. Would it have been better to put it into the maint branch and is it it possible to shift it from master to maint so it goes in for 3.6? I copied the 2 files changed into a 3.5 downloaded source and it still builds and works fine but it is throwing a warning about deprecation of gtk_menu_popup() during compilation. I will fix that. David - 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
Re: [GNC-dev] GnuCash 3 on Linux
Wm, I backup all user data including hidden directories on my hard disk to an NAS so no matter where it is I have it copied. I do full backups monthly with daily incrementals and usually retain them for 3 months these days. I off load the backups onto USB for offsite storage as well now that they are big enough. I'm retired so the data flow is very much reduced these days. I also do selective backups to offsite cloud locations of critical data including GnuCash. For those I backup all the data in the locations given for v3+ in the wiki Configuration Locations for GnuCash. I don't bother with the aplication config in /usr/local/etc/gnucash as I don't edit anything in it. My desktop is also synced with my laptop and my wife's laptop- not really secure as a backup as any saved changes get propagated including those that might take the system down but it has helped with some simple problems. My NAS is NFS4 based so my Linux boxes communicate pretty easliy with it (it is mounted when switched on on all computers and Samba takes care of the one Windows machine. Took a while to setup but the NAS initiates backups to itself on a schedule. Also backs up our mobile phones. When I was operating a business and in a past side job as a systems manager, I used a Towers of Hanoi (annual/quarterly/monthly/weekly/incremental) backup plan. The locations I would backup as a matter of course would be the ones labelled GNC_DATA_HOME and GNC_CONFIG_HOME ( and all files and subdirectories in those locations) in the diagrams. I haven't bothered customising the gtk-3 setup for GnuCash so I wouldn't bother with the GTK locations. David - 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
Re: [GNC-dev] Transactions vs Splits
Alen, The multicurrency transactions are a problem because at the moment GnuCash is introducing a spurious unrelated amount into the transaction. For eg I had a simple $100 AUD debit to an AUD Savings Account with a split to a Savings USD account for $110 USD. This is correctly exported but when reimported it introduces an amount of $1000 USD. The following CSV when imported Date,Transaction ID,Number,Description,Notes,Commodity/Currency,Void Reason,Action,Memo,Full Account Name,Account Name,Amount With Sym,Amount Num.,Reconcile,Reconcile Date,Rate/Price 15/11/18,b60da83af9b84334aa2f5e129c23016f,,Transfer with currency exchange,,CURRENCY::AUDAssets:Current Assets:Savings Account,Savings Account,$100.00,100.00,n,,1.00 ,Assets:Current Assets:Savings USD,Savings USD,-$110.00,-110.00,n,,10/11 produces SavingsAccount_From_AUD_ML_004.png <http://gnucash.1415818.n4.nabble.com/file/t375329/SavingsAccount_From_AUD_ML_004.png> and in the Savings USD account register this produces 2 transactions on import Savings_USD_From_AUD_ML_005.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_005.png> and when you open the first transaction to display the splits Savings_USD_From_AUD_ML_split1_006.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_split1_006.png> and the second transaction created is Savings_USD_From_AUD_ML_split2_007.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_split2_007.png> The multi-currency import is just not working correctly at all at the moment. I'm doing the imports into a pristine data file each time so I can see exactly what is happening when I vary the import conditions. I was waiting to test out a few more possibly related things for multiline imports of transactions between accounts in the same currency before reporting it as a bug. This will help with isolating where it is in the code. The Price is what should control the currency conversion. The book currency I am using is AUD so a price of 10/11 is the conversion rate from USD to AUD in my case for the second split. The price on the split to the AUD Savings Account is 1.00 which is as expected. This is how the account registers appeared before exporting the transaction. The way it is supposed to work is if I look at the AUD "Savings Account" register all amounts are rendered in the currency for that account, so the register appears as Savings_Account-GnuCash_Initial_013.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_Account-GnuCash_Initial_013.png> and if I look at the "Savings USD" account register all amounts are in USD as follows Savings_USD-GnuCash_Initial_015.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD-GnuCash_Initial_015.png> . I would be very cautious about using the export/import on multicurrency transactions at the moment I got into this because I some changes to the import matcher late last year and while testing them out noticed that the CSV documentation was way out of date when I was documenting my changes. I started to rewrite the documentation but then found anomolies in how it worked I couldn't understand after the release of V3. Geert really hadn't had time to debug it fully with the load of bug fixes after the v3 release so I undertook to go through it methodically initially mainly to look at the problem that GnuCash v3.2 could not import its own exported files, particularly in the multiline format. I'm preparing a documented report to identify the bugs in a reproducible manner. If Geert is unable to tackle fixing the bugs then when I finish doing that, then I will start working on fixes for them and updating the documentation. The CSV importer still seems to be able to work for what was its original functionality, importing CSV exports form bank accounts etc where single line mode is usually adequate. My bank exports categories in the record which I can setup so I have these set to match the GnuCash Income and Expense accounts I use. The majority of my transactions are usually matched on import but I have never been sure whether it is using the categories or the Bayesian matching algorithm or both. I suspect the latter as some of the transactions I regularly have problems with are ones where the provider uses a different reference number in the description field each time. Their number has a fixed part with a sequential number tacked on the end. The matcher algorithm tokenizes the information in the description field but it can't separate the fixed part of the number from the variable part so it rejects the match. The rest of the description field is not sufficient to override this. I'll have to delete the data file for te bayesian matcher between each import when i get around to testing how that works in detail. - David Cousens -- Sent from: http:/
Re: [GNC-dev] Transactions vs Splits
Hi Alen, >I see that, with Multi-split checked, I can no longer select the Transfer >Account destination field. This is a dead end for my current approach, using >Transfer Account. With a multisplit multiline record there should be no need. GnuCash should interpret the following lines as transfer accounts I suspect the mismatches you get are a problem with GnuCash not interpreting the multiline splits correctly. It is why I am doing a structured testing of the import capability. >At the last screen, I now get all mismatches as the destination account is >missing and I'm prompted to select one. This makes no sense as I could have >simply selected that at the first screen and save my matcher schema. >Should I raise this as a bug or am I misunderstanding how this is supposed >to work? The account selection in the first window is AFAIK intended to select an account for all transactions to be imported into. It is intended I think for the case where the records to be imported do not specify the account they are being imported to. Where the transaction has only 2 splits and both accounts which are the targets of the splits are specified then the single line format with both the account and transfer account are specified is appropriate as you have done. You could equally treat "Cash" as the transfer account and "Food:Dining out" as the account being impoorted to if you swapped the deposit and withdrawal columns as well. The mismatches seem to indicate that GnuCash is not recognizing the account in the second line as the transfer account which it should. You can raise it as a bug if you wish. I will be testing all the import settings fairly methodically in in the next few days so if you don't I will in any case. If you have already I can just add the results of my testing as a comment. The notation transfer account is not one as an accountant that I really like. It only makes sense when transferring funds between two asset (or liability accounts) but many software developers and users have adopted it so it is now part of the language. My view of a transaction is that it consist of two or more splits each of which has a target account which is debited or credited by that split. Where the multiline capability comes into its own is in dealing with transactions with 3 or more splits and it really only needs to be used in this case. David - 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
Re: [GNC-dev] Transactions vs Splits
Alen When you are importing a multiline exported transaction you should see a multiline checkbox at the bottom of the first window. You may get multiline import to work if you select this as it tells GnuCash to look for following lines which are part of a single transaction. David - 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
Re: [GNC-dev] Transactions vs Splits
Alen, Each exported transaction occupies at least 2 or more lines, one for each split in the transaction. The following is an exported multiline format single transaction for a credit of $100 to the Savings account with splits which debit the Checking account by $50 and the cash in Wallet account by $50. The formatting may not survive the posting but I will separate each line with two newlines: Date,Transaction ID,Number,Description,Notes,Commodity/Currency,Void Reason,Action,Memo,Full Account Name,Account Name,Amount With Sym,Amount Num.,Reconcile,Reconcile Date,Rate/Price 04/03/2019,2a9b1f7950ab4f388e2c4ae3ac8fe1c3,,Tfr to Cash in Wallet,,CURRENCY::AUDAssets:Current Assets:Cash in Wallet,Cash in Wallet,$50.00,50.00,n,,1.00 ,Assets:Current Assets:Checking Account,Checking Account,$50.00,50.00,n,,1.00 ,Assets:Current Assets:Savings Account,Savings Account,-$100.00,-100.00,n,,1.00 If during export you select the Simple Layout in the first window of the export procedure you will get a single line format but this does not work for transactions which have more than 2 splits e.g. it only exports the following: Date,Account Name,Number,Description,Full Category Path,Reconcile,Amount With Sym,Amount Num.,Rate/Price 04/03/2019,Assets:Current Assets:Savings Account,,Tfr to Cash in Wallet,-- Split Transaction --,n,-$100.00,-100.00,1.00 It cannot deal with more than 2 splits in a transaction. This is why Geert has been setting up the multi-line export and import. I will get to testing the import of these transactions either tomorrow morning or Thursday. I don't know yet whether it is possible to import them in the multiline format with 2 or more splits yet. i am working slowly and documenting everything i do so the developers have enough data to start identifying where the problems are. Once I understand it I will update the wiki and then get the Help/Guide docs up to date for the next release. I suspect the bug fixes might not make it until the next release comes out If you are only exporting and importing transactions with 2 splits you should be able to get it to work. I would create a dummy transaction first and export it, delete it in the book and then reimport it. There is an identified bug in the Export Transactions to CSV where transactions cannot be exported on the date they are created so it is better to use Export Transactions from Active Window to export a dummy transaction. Bob Fewel is already working on a fix for this. I normally setup a test datafile to work with while exploring this rather than use a real datafile so that other transactions don't complicate life. David Cousens - 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
Re: [GNC-dev] 3.4 metadata location
John, Added a note to the wiki Configuration Locations page to indicate that it may not be applicable to flatpak , snap and other such packages. David Cousens - 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
Re: [GNC-dev] CSV Import Format
No problem Geert. I'm the one pressuring myself David - 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
Re: [GNC-dev] CSV Import Format
Geert, I can feed you what I've done so far with the multiline, double currency transaction. My apologies for taking so long. My wife is a poet and I'm the publishing company these days. She handed me the latest book of poetry to edit and typeset for printing along with a manuscript from another friend just after I started on testing the importer. I made it back to the importer the day before yesterday. I have presumed the multiline import is working for accounts in the same currency but haven't actually tested it so far. It would have been logical to do that first. I have also ignored trading accounts so far either. I am counting on that being largely dealt with if the multicurrency transactions work. The results so far are attached. ExportImportCurrencyTransaction.odt <http://gnucash.1415818.n4.nabble.com/file/t375329/ExportImportCurrencyTransaction.odt> I will continue and check out a multiline import to accounts with the same currency with 2 or more splits. One thing I am not clear on is whether or not the single line mode is meant to be able to import a two split transaction when the split target currencies are in the same currency without relying on the matcher. I am presuming it is. My secondary aim is to learn enough to be able to put some documentation together for the importer once I have some idea of what aspects are working. Unfortunately I will have another break as I am off to Singapore in 2 weeks. I will keep appending to the document and send you updates. Cheers David - 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
Re: [GNC-dev] CSV Import Format
Alen, The new version of the CSV importer is not documented very well yet. The multiline capability is problematical, definitely where transactions with accounts in two or more currencies are involved. It basically doesn't work at the moment. I'm exploring that and mid writing a report to guide bug fixing at the moment. I havent checked out multiline import for transactions where the splits are to accounts in the same currency yet. That's my next job. If your data is all imported to a single account, set the account to be imported to in the dialog, rather than each CSV record you basically only need a date , a description, the transfer account, the amount (and set whether it is a deposit or withdrawal) and the single line mode works OK. I import my Paypal account data with this sort of setup with minimal problems. If the account specified in the record is the account to be imported to I have not yet tested out setting a transfer account in a single line record. You can always not set it and rely on the matcher to assign accounts but it will require training. I.e. hint you need to import small batches of data first. One trap is the locale setting doesn't necessarily set up the date format correctly so it pays to select that explicitly in the date format field. If the import data has column headers set the skip to 1. David Cousens - 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
Re: [GNC-dev] GnuCash 3 on Linux
Wm Diagrams are up https://wiki.gnucash.org/wiki/Configuration_Locations. The wkiki markup is crude but works. I will try later to implement a scroll box to better accommodate narrow width monitors and mobile devices. Geert pointed out a few corrections re what are merely labels for locations and what are actual definable environmental variables which are now incorporated. The original text on the wiki did not distinguish too clearly between what were labels for locations and what can be actually set as locations. It was there but obscure. In the diagrams these are distinguished as clearly as I am able to. On Linux at least those environment variables (not the ones which are merely labels) are not created on installation. They can be and then GnuCash should use the locations defined by them (I haven't verified this mainly because I don't have the need to use it). In principle at least you could define GNC_DATA_HOME and GNC_CONFIG_HOME to point to the book location or a subdirectories of the directory containing the book. >The problem with the gnc code for transition is that it placed no value >on who accessed it first. Why would it? GC is not designed as a multiuser program for a multiuser environment. It has no user structure to define authorization levels and no code to restrict access to specific functionality. While there is perhaps an ambition to move in this direction longer term, it is nowhere near there yet. Admittedly the release notes for V3 only obliquely mention the relocation of the user configuration location and that in hindsight should perhaps have been highlighted more. But it came up pretty quickly in the forum http://gnucash.1415818.n4.nabble.com/GNC-Saved-Report-Configurations-Missing-After-Upgrade-to-v3-td4700786.html#a4700793 along with the cure of renaming saved-reports-2.4 to saved-reports-2.8 in the new directory. >The place was identifiable relative to the book. 3.x changed that. To a place which is also identifiable relative to the book. The changes going to V3 also make it possible (at least in principle) to co-locate the configuration with the book by defining GNC_DATA_HOME and GNC_CONFIG_HOME which was not possible under V2.6. Again you missed the point that the Save and Save As options in the reports toolbar and menu don't or at least shouldn't save the report per se, but save only the configuration information for a report. What level of personal information gets saved in the configuration is not clear to me. I can conceive of a situation where a number of books use a stock standard account heirarchy and one configures a report to depend on that heirarchy but if account guids are incorporated this becomes of limited usefulness wrt the ability to transfer reports. The report configuration should not contain the information directly and only have pointers to locate the information which is contained only in the book. Is that not the case? David Cousens ----- 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
Re: [GNC-dev] Building 3.4 on Mint 18.3
Jacob, The reports use Scheme which is implemented in the Guile libraries so they are a likely candidate. The dependencies for V3 are listed https://wiki.gnucash.org/wiki/Dependencies which is a breakout from the general instructions for building at https://wiki.gnucash.org/wiki/Building and the Linux instructions at https://wiki.gnucash.org/wiki/Building#Building_on_Linux_Distributions. Installation of the dependencies is described https://wiki.gnucash.org/wiki/Installing_Dependencies. These instructions were originally formulated on Linux Mint 18.3/Ubuntu 16.04 with v 2.6 but have been updated for V3 and also for Linux Mint 19.1/Ubuntu 18.04 but have also been used for Ubuntu 18.10 as well. Check the Guile library version you have installed. The Cmake command should be checking this and stopping if the required library versions are not present. David Cousens - 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
Re: [GNC-dev] GnuCash 3 on Linux
Hi Geert Thanks for the corrections. I'll make those that are labels and not environment variables black to indicate that. I've now indicated what are environment Variables but I'm hoping that doesn't imply they should necessarily be editable. I've put do not edit notes against the HOME variables. I haven't mentioned XDG_DATA_HOME and XDG_CONFIG_HOME in the diagrams. I am intending readers to go to the text explanations for more detail where required. David - 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
