Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Thank you for trying Adrien. This budget bug is proving to be a major headache. I really need more beta testers, especially with ability to build from my branch. Of note: * previous methodology was: in a period, budgeted income, minus budgeted expense and any asset/liability transfers, must result in zero. This assumes credit-accounts sign reversal. * future methodology is: in a period, all natural budget amounts must equal zero. i.e. incomes being negative, will be balanced by positive expenses etc. My plan to try fix this for good is to *remove* all totals except the "Remaining to Budget"; from my understanding this is the only total of any use. Alternatively, another plan is to switch to future methodology and forego backward compatibility in existing budgets, for use in 4.x or 5.x. On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > I just posted my first result and impression to the bug report, though I’m > sure you saw that already. (this is more for the benefit of list readers > not following the bug) > > The signs aren’t making sense, and the amounts aren’t adding up correctly. > > Regards, > Adrien > > > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam < > christopher@gmail.com> wrote: > > > > Next addendum: your existing budget data will behave well when reverse > > balances=credit accounts, but the *featured* data will be stable with > *any* > > reverse balances global preference option. > > > > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, < > christopher@gmail.com> > > wrote: > > > >> > >> > >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, < > christopher@gmail.com> > >> wrote: > >> > >>> Deadline is 11 April at noon GMT, so, about 34 hours from now. > >>> > >>> For both: *existing* datafile and especially *4.x-featured *datafile > (in > >>> bug report). > >>> > >>> Please test: > >>> - creation of budget amounts > >>> - use estimate to prefill cells > >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately > >>> > >> > >> Addendum this is not simply an arithmetic test; it *must also > >> confirm that the totals and signs are sensible for the purpose of > >> budgeting. Hence the difficulty of a one person coder to make it work. > For > >> example, we can budget a liability account regularly until we have > enough > >> deposit for a huge loan, or we can budget a liability account regularly > for > >> the loan repayments. IIUC both approaches are "valid" but the signs > will be > >> opposite. Other counter examples likely exist. > >> > >> - budget.scm report (optionally other budget reports but these are lower > >>> priority) and especially difference column. > >>> > >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < > >>> adrien.montele...@lusfiber.net> wrote: > >>> > Thank You! This makes it so much easier to test. I’ll give the > flatpak a > spin and see what I find. I still haven’t set up a build environment > for > Mac yet. (and watching a recent thread on the subject makes it look > daunting compared to Linux) > > This is a busy weekend for me though. What kind of time frame do you > have and is there something in particular you’re looking to find. > (other > than just loosely that the totals appear to work) > > Regards, > Adrien > > > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < > christopher@gmail.com> wrote: > > > > 2020-04-07 nightly available at > https://code.gnucash.org/builds/win32/maint/ > > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ > - use > > between 2020-04-04 and 2020-04-10 > > > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < > christopher@gmail.com> > > wrote: > > > >> This topic is about budgets. > >> > >> We now know that budgets are currently inherently flawed: they > *assume* > >> that sign-reversal = credit-accounts, and do not work well at all > with any > >> other sign-reversal option. In addition, there was a feature request > (bug > >> 781345) that introduced budget equity into the equation, and I still > do not > >> know whether a budget equity amount is a correct approach. > >> > >> In 4.x series there is a planned *fix* which will scan budget > amounts, > >> use heuristics to determine the most likely sign-reversal approach > used > >> during budget creation, internally unreverse the amounts, and > upgrade > the > >> datafile so that it cannot be damaged by 3.7 or earlier. > >> > >> Therefore 3.8 was the first release which could handle both old and > fixed > >> budget amounts. Unfortunately, the interpretation of budget signs > was/is > >> very difficult, which explained the switch to > >> asset/liability/equity/income/expense totals, which are impervious > to > >> budget signs. Unfortunately users mis
Re: [GNC-dev] iOS app
Hello, It is from scratch, it is written in swift, it decompresses the .gnucash file then parses the xml file and displays the account tree. Sent from my iPhone > On Apr 18, 2020, at 5:37 AM, Geert Janssens > wrote: > > An iOS app that can view gnucash files is certainly nice. > > Is it a from-scratch implementation or did you reuse our gnucash code for it > (the latter would be really awesome) ? > > Regards, > > Geert > > Op vrijdag 17 april 2020 18:17:28 CEST schreef Camille Rizko via > gnucash-devel: > > Hello, I developped an iOS app that allows me to view my gnuCash files on > > iphone or ipad. It shows the list of accounts with totals. It also shows > > Balance sheet to date, Balance sheet last year, income statement last year > > and income statement to date. Is this of interest to the community? > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About 3.9 and reconciliation balances
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] Can a module call a function from another module?
Thanks for all the background, I understand it a lot better now. Indeed, I've noticed the intermingled UI/logic code in places, and I agree that's not good. What I want to try is launch the reconcile from the import, exactly like aqbanking, so that shouldn't be a problem. No specific implementation function. Jean On 4/18/2020 12:02 PM, John Ralls wrote: One other consideration: The dependency should make sense architecturally: A dependency on code in libgnucash/engine nearly always makes sense; a dependency in the register on a function in import/export does not. That doesn't mean that you should copy-and-paste the code instead, it means that the code should be extracted from import/export and moved somewhere that does make sense. The logical place for GUI code is gnome-utils while business logic code belongs in libgnucash/engine--and note that there is a *lot* of business logic code that has gotten intermingled with GUI code and needs to be refactored out. It's a major maintenance headache because it often means that the same business logic is implemented in more than one place, often with subtle differences. Whether that's the case for your window-reconcile.c example depends on what you need to do: If you want to launch the reconcile window from the OFX importer the way AQBanking does, no problem. If you need some implementation function in window-reconcile.c then it strongly suggests that that function is of more general use than just the reconcile window and probably belongs somewhere else. Regards, John Ralls On Apr 18, 2020, at 5:29 AM, Geert Janssens wrote: First off, modules are mostly on the way out. I have been working on removing most uses of those and plan to eliminate even more. The gnc_module code itself will remain until we have a better alternative. Other than that, yes, you are allowed to include headers from other "modules". Or more generally from other compile units (the objects defined with add_library or add_object). There are other restrictions though: 1. you may have to add the proper include and library directories to the compile unit's CMakeLists.txt file. Without this the compiler won't find the header file (and later the library to link to) 2. In doing so you should be careful not to introduce circular dependencies. That is if unit A already depends on unit B, you can't make unit B also depend unit A. 3. reconcile-window.h is a C header file, while gnc-ofx-import.cpp is a C++ source file. You may have to include it inside an 'extern "C"' block. You didn't provide any details as to what errors you got, so at this point it's hard to tell what exactly went wrong. Regards, Geert Op zaterdag 18 april 2020 07:29:15 CEST schreef jeanl: Devs, I have a question to which I can't find an answer. It is possible for a function from a module (say import-ofx) to call a function from another module (declared in "reconcile-window.h" for example). I'm not able to include reconcile-window.h from gnc-ofx-import.cpp , I assume the build isn't setup to include the right headers. But perhaps this is by design and a module isn't supposed to be able to call another one. In that case, how can we make it so a function from a certain module is followed by a call to a function from a different module automatically? J. -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ 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] Can a module call a function from another module?
One other consideration: The dependency should make sense architecturally: A dependency on code in libgnucash/engine nearly always makes sense; a dependency in the register on a function in import/export does not. That doesn't mean that you should copy-and-paste the code instead, it means that the code should be extracted from import/export and moved somewhere that does make sense. The logical place for GUI code is gnome-utils while business logic code belongs in libgnucash/engine--and note that there is a *lot* of business logic code that has gotten intermingled with GUI code and needs to be refactored out. It's a major maintenance headache because it often means that the same business logic is implemented in more than one place, often with subtle differences. Whether that's the case for your window-reconcile.c example depends on what you need to do: If you want to launch the reconcile window from the OFX importer the way AQBanking does, no problem. If you need some implementation function in window-reconcile.c then it strongly suggests that that function is of more general use than just the reconcile window and probably belongs somewhere else. Regards, John Ralls > On Apr 18, 2020, at 5:29 AM, Geert Janssens > wrote: > > First off, modules are mostly on the way out. I have been working on removing > most uses of > those and plan to eliminate even more. The gnc_module code itself will remain > until we have a > better alternative. > > Other than that, yes, you are allowed to include headers from other > "modules". Or more > generally from other compile units (the objects defined with add_library or > add_object). There > are other restrictions though: > > 1. you may have to add the proper include and library directories to the > compile unit's > CMakeLists.txt file. Without this the compiler won't find the header file > (and later the library to > link to) > > 2. In doing so you should be careful not to introduce circular dependencies. > That is if unit A > already depends on unit B, you can't make unit B also depend unit A. > > 3. reconcile-window.h is a C header file, while gnc-ofx-import.cpp is a C++ > source file. You may > have to include it inside an 'extern "C"' block. > > You didn't provide any details as to what errors you got, so at this point > it's hard to tell what > exactly went wrong. > > Regards, > > Geert > > Op zaterdag 18 april 2020 07:29:15 CEST schreef jeanl: >> Devs, I have a question to which I can't find an answer. It is possible for >> a function from a module (say import-ofx) to call a function from another >> module (declared in "reconcile-window.h" for example). >> I'm not able to include reconcile-window.h from gnc-ofx-import.cpp , I >> assume the build isn't setup to include the right headers. >> But perhaps this is by design and a module isn't supposed to be able to call >> another one. In that case, how can we make it so a function from a certain >> module is followed by a call to a function from a different module >> automatically? >> J. >> >> >> >> -- >> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Testing python
I use the python bindings regularly but I've never got any warnings or errors such as you describe. Just to cover the basics first, are you sure you didn't want to issue the venv command with the '--system-site-packages' switch? Did you have pygnucash loaded to the pip of the python you used for venv? Or instead did you make sure that in your venv you have included the path to your tinkered bindings in your PYTHONPATH? And you activated the venv before using? Sorry if this is all basic stuff you already know about. *Mark* *episte...@gmail.com * *(613) 447-5385* On Sat, Apr 18, 2020 at 10:08 AM andygoblins wrote: >I'm tinkering with the python bindings, but I'm having trouble testing >the results of my changes. Could anyone give me some advice? >Currently, I build gnucash with ninja and then run 'python -m venv >' to set up a virtual python environment right next to the >fresh build. But when I try to import gnucash in the virtual >environment, it doesn't load any of the backends: >WARN failed to load gncmod-backend-dbi from relative path >ERROR required library gncmod-backend-dbi not found. >WARN failed to load gncmod-backend-xml from relative path >ERROR required library gncmod-backend-xml not found. >Any ideas on how to fix my path so I can load backends in my test >environment? > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About 3.9 and reconciliation balances
Oops, I misunderstood the turn this thread took. My mistake. I don't have any particular comments on an autofix to clean XML files with inconsistent reconciliation dates and the current approach GnuCash has for reconciliation. My comments were for some future many months->years away in a later GnuCash that has an alternate approach to reconciliation. Sorry if I derailed anyone's reading. --Dale On Sat, Apr 18, 2020 at 12:24 AM David Cousens wrote: > 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 > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Testing python
I'm tinkering with the python bindings, but I'm having trouble testing the results of my changes. Could anyone give me some advice? Currently, I build gnucash with ninja and then run 'python -m venv ' to set up a virtual python environment right next to the fresh build. But when I try to import gnucash in the virtual environment, it doesn't load any of the backends: WARN failed to load gncmod-backend-dbi from relative path ERROR required library gncmod-backend-dbi not found. WARN failed to load gncmod-backend-xml from relative path ERROR required library gncmod-backend-xml not found. Any ideas on how to fix my path so I can load backends in my test environment? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] iOS app
An iOS app that can view gnucash files is certainly nice. Is it a from-scratch implementation or did you reuse our gnucash code for it (the latter would be really awesome) ? Regards, Geert Op vrijdag 17 april 2020 18:17:28 CEST schreef Camille Rizko via gnucash-devel: > Hello, I developped an iOS app that allows me to view my gnuCash files on > iphone or ipad. It shows the list of accounts with totals. It also shows > Balance sheet to date, Balance sheet last year, income statement last year > and income statement to date. Is this of interest to the community? > ___ > 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] Import multiple OFX
Op vrijdag 17 april 2020 18:01:30 CEST schreef jeanl: > Hi Devs, > I have code that enables importing multiple OFX in one shot. It's actually > *almost* already supported by GC, and required few changes. > - The file import dialog needs a new option to allow multiple-file > selections > - Then there's simply a loop over files using the regular code. > > This is great for some people (me) whose banks don't combine ofx files, > makes the workflow a lot nicer. > > What do you think, should I do a PR for this? > Jean > Note: the normal file dialog returns a char* . I added a new type > IMPORT_MULTIPLE that enables the multiple file selection, but then the > return must be a GSList*. It's easy (and hacky) to masquerade this GSList* > as a char*, and this requires no change anywhere else. The alternative is to > add 1 input parameter GSList** to the file dialog, but this requires > changes in many files since there are no default parameter values in C. > Feel free to PR it, that will be easier to discuss it than here. Without seeing your code it's hard to grasp what exactly you mean. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Can a module call a function from another module?
First off, modules are mostly on the way out. I have been working on removing most uses of those and plan to eliminate even more. The gnc_module code itself will remain until we have a better alternative. Other than that, yes, you are allowed to include headers from other "modules". Or more generally from other compile units (the objects defined with add_library or add_object). There are other restrictions though: 1. you may have to add the proper include and library directories to the compile unit's CMakeLists.txt file. Without this the compiler won't find the header file (and later the library to link to) 2. In doing so you should be careful not to introduce circular dependencies. That is if unit A already depends on unit B, you can't make unit B also depend unit A. 3. reconcile-window.h is a C header file, while gnc-ofx-import.cpp is a C++ source file. You may have to include it inside an 'extern "C"' block. You didn't provide any details as to what errors you got, so at this point it's hard to tell what exactly went wrong. Regards, Geert Op zaterdag 18 april 2020 07:29:15 CEST schreef jeanl: > Devs, I have a question to which I can't find an answer. It is possible for > a function from a module (say import-ofx) to call a function from another > module (declared in "reconcile-window.h" for example). > I'm not able to include reconcile-window.h from gnc-ofx-import.cpp , I > assume the build isn't setup to include the right headers. > But perhaps this is by design and a module isn't supposed to be able to call > another one. In that case, how can we make it so a function from a certain > module is followed by a call to a function from a different module > automatically? > J. > > > > -- > Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
