[GNC-dev] are all the public names for gnc still valid ?
been a while since I tried them but some don't seem to be working -- Wm ... ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] v5 breaks multicol reports, why didn't someone check this behavior?
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
Re: [GNC-dev] v5 breaks multicol reports, why didn't someone check this behavior?
In case you are unusually stupid, try the recipe before replying you fool. 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
[GNC-dev] v5 breaks multicol reports, why didn't someone check this behavior?
In case you think this belongs in 798809 – Multicolumn report error when reopened after saving. (gnucash.org) <https://bugs.gnucash.org/show_bug.cgi?id=798809> I agree, it does belong there. The problem is the fuckwit in charge there doesn't allow reports from people that don't suck his penis. When will someone take the "I'm important I say what gets to be a bug" people to task? Anyway. This particular bug is breaking v5 for anyone that uses multicol reports. Those people are, ordinarily, people that group a set of reports together, for example, a set of accounts. An income statement, a balance sheet, that sort of ordinary thing. Those report combinations no longer work. Existing reports, those that work using v4_14 work under v5_n *until* a save is made to the report store. As soon as a save is made to the report store using v5 one or more of the multicol reports is trashed. Basically, v5 is destroying existing reports. I am fortunate, I have scripts from the last time the reports were fucked up what the scripts do is strip out the individual reports and put them in a directory so saved-reports-2.8 can be resurrected after it is trashed 2 questions Why is the person in charge of bugs still wasting people's time masturbating over who said what years ago rather than allowing conversation ? Why is the person who wrote the code that broke the reporting system not responding in bugs ? These are both *human* issues. -- Wm ... ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] alphavantage time out fix not obvious
I can't find a bug and fix in the list for the alphavantage time out problem. It was certainly discussed here. Do I have to make a bug for it or hand roll again? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] OARS classification of gnucash
On 22/08/2019 19:33, Geert Janssens wrote: Op donderdag 22 augustus 2019 19:50:38 CEST schreef John Ralls: On Aug 22, 2019, at 10:00 AM, Geert Janssens wrote: Gnome and Flathub use age rating data to classify applications as appropriate or not for certain groups of users. Both are using the Open Age Rating Service (OARS) [1] for this. I went to the trouble of filling the questionnaire for gnucash and ended up with this rating: mild "social-info" may be a bit odd, but when selecting this option, I was considering the AlphaVantage API key which I presume can/will be used by Alpha Vantage to track the user. I expect other price sources are tracking a lot more than AlphaVantage via F::Q, maybe we should pass the query on to the F::Q team? Does anyone have remarks/issues with this classification ? If so, please share, otherwise I'll use this for the next gnucash release. [1] https://hughsie.github.io/oars/ I don't know that it matters much, I wouldn't really expect a 12 year old to be interested in GnuCash anyway... and besides, 12 year olds know how to get around most age restrictions. Sure, it doesn't matter that much, but the OARS piqued my curiosity. My initial reaction was similar to JohnR's, "what has this got to do with us?" Also you're probably looking for more in it than it really does. It just labels applications. There's no actual restricting going on. Having said that, it is thanks to a system as OARS that users can easily know our application is not riddled with advertisements or trackers. For us that may be obvious. That sounds right. We're so used to this in the open source world. Flathub (or the Ubuntu app store for that matter) however also ships commercial applications, which do have advertisements or language that's not acceptable in all circumstances. Hmmmn, sourceforge.net (which is where many people get their gnc from) isn't exactly ad-free either. If we don't use them will the "owned" servers stand up to demand? I don't think that there's anything tracking related that the Alphavantage API key gets them. They can already get the requesting IP and associate the list of requested prices with it just like all of the other price sources. That's not to say that GnuCash users who use price quotes or online banking aren't exposed to tracking, just that it's not limited to Alphavantage. It's anyway pretty minor compared to web-browser use, so I went looking for Epiphany's age rating and couldn't find one. The age rating is fairly new and still voluntary. So many applications don't do it yet. I think you need to be on the weird side of political beliefs before you think understanding money, double entry accounting and similar stuff should be age-rated. Unless you are the aging leader of an African or Asian despotic state ... or the elected leader of the USA. Further the definition of "Mild" according to the OARS is: "Using any online api" We do use online api's via Finance::Quote so that's why I selected it. How much tracking actually goes on we don't know. We don't have to. We only warn the user they may potentially be tracked. I'm not sure where this is heading, however, thanks for raising this, Geert. P.S. people that care are allowed to disagree :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] owner-report, receivables-aging etc
On 19/07/2019 09:56, Christopher Lam wrote: Wish to canvas opinion on what is considered best practice for the following real-data simulations, for rebuilding owner-report and aging-report. This illustrates current buggy behaviour. * I have a $100 customer invoice, posted- and due-dates 6 weeks ago. * I have a $50 credit-note to same customer, posted and due-dates are 2 weeks ago. Intuitively the customer owes $50. But I haven't formally yet linked the credit-note to the invoice though. The $100 invoice is still unpaid Attachments show: * the Customer Report counts the $100 and $50 separately into separate owing date ranges. * the Receivables Aging report shows the CN $50 was automatically used to fund the $100 invoice, via FIFO (paying oldest invoice first). Which behaviour should we standardise on? accounting practice varies about this. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Adding module to make GnuCash more valuable
On 23/07/2019 18:18, John Ralls wrote: That would be *way* out of scope for GnuCash. The only effect on accounting is when the change in ownership of the inventory is booked. Deciding that is completely external to GnuCash, which doesn't even do cost accounting for WIP inventory. It might be in scope for an ERP program like odoo (https://www.odoo.com/) that does do cost accounting, but even that's doubtful and most of an ERP suite wouldn't be useful to a freight forwarder. (I used to be the production control manager at an integrated circuit manufacturer so I have a small understanding of international shipping.) You might invert the problem, though, and use GnuCash as the accounting backend for a stand-alone shipping management program. Way out of gnc's scope. gnc as a backend is useful. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
On 25/05/2019 23:53, Christopher Lam wrote: Basically anyone who runs a custom .scm file. Once again you are saying custom without making it clear what you mean. For the sake of clarity, I do not think you, Christopher, are doing this with the intention of being unclear. Some people (hopefully not too many) may have altered an .scm file provided as part of a standard gnc installation. I think we should presume they did that at their own risk. My concern is if you are proposing something else. for example, what if someone is depending on a perceived fault in the current reporting system? <-- I don't know if I am doing this but I might be. Possibly more politics than sense, but: I am positive about gnc's reporting being improved, I'm just not sure why we are doing more scheme rather than more sql. Many function names are being deprecated; they are not used in main code anymore but custom .scm files may call them, and will error out after removing these functions. Hmmmn, OK, I still don't know what your definition of custom is :( -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
On 24/05/2019 04:07, Christopher Lam wrote: Hi John My plans for 4.0 will be - remove *all* deprecated exported functions and deprecated code paths - enable book-accounting-period preference I'd urge anyone with custom reports will observe the console or tracefile, and watch for any scheme deprecation warnings while running latest versions of GnuCash -- old functions are due a major cleanup. If there are, please let us know via devel or bugzilla (and attach custom report). How are you defining a custom report, Chris? Do you mean anything anyone has in saved-reports-2.8 or similar? If so that is definitely non-trivial. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Use trading accounts only for currency conversion
On 05/05/2019 09:41, cicko wrote: As I've written in https://bugs.gnucash.org/show_bug.cgi?id=797227: I suspect that the purpose of the trading accounts was to account for the loss/gain in currency conversion (only). Your suspicion is incorrect. Not sure if applying the trading accounts for other commodities makes sense. Maybe you should give an example of where trading accounts don't work for a commodity in a "home" currency (or whatever it is we are calling it at the moment). These should be accounted for through Capital Gains/Losses accounts. Are you suggesting that gnc takes a jurisdictional view? Tax regulations are extremely complex and differ widely between one country and another. At the moment we generally think that is best left to the user understanding their government's legislation. I find that mixing other commodities trades in trading accounts almost destroys their usefulness. Once again, I think an example would be useful. Limiting their implementation to Currency commodities only would make more sense. What do others think? I think you need to come up with a better way of doing things before you tinker with trading accounts. I agree the name is misleading to some so you're welcome to suggest changing that. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] buglist needs tidying
I know I am not the favourite person here, however, some things need to be said. The "known issues" list at http://gnucash.org/news.phtml is a mess and needs tidying. There are a number of duplicate reports. They don't help anyone because each of the reporting individuals is left thinking their problem isn't being attended to. I know they are being attended to or at least considered in some cases, they should be brought together. I think triage is required rather than divide and rule. There is more than one substantive issue in the buglist (and I don't mean the issues I have raised). What should the priorities be? Should the dev effort be directed to the interface or the actual? I'll leave it at that, if this gets to be published take a look at some of the things on the list and try to work out which ones you think are significant. I'm not arguing for populism, I'm saying we should think about what the gnc priorities are, merge some of them together and see if we have some direction after that. I repeat, I know I have upset many people here but ... -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] libpsd2, opinions?
On 22/03/2019 18:41, Marcello Stanisci wrote: Dear GnuCash devs, in the main context of the european directive PSD2 (that basically mandates all the banks to expose a REST API for everyone to use their online-banking services), I noticed that there is not yet a modern, well-documented, well-tested, and Free Software library that would implement all the major standards -- like e.g. EBICS and FinTS. Do you think that starting a C project (libpsd2) for a libary that can address all the issues I mentioned above would make sense / be good? In broad terms, yes. Unfortunately gnc is a mix and match when it comes to international standards and is lagging when it comes to implementation. We love the idea but we're just to head-up-our-own-anus to do anything about it in the next few years. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book-currency
On 04/07/2018 03:34, John Ralls wrote: I think it was Alex that said: Today, in file->properties->Accounts tab, you can turn "trading accounts" on or off. At your peril. As far as I can tell they're either on or off, switching breaks stuff. I propose to change this to a selection of three alternatives: use trading accounts, specify a 'book currency', or neither trading accounts nor book currency. The practical and the theory aren't going to mix well. If trading accounts is selected, it would work as implemented by Mike. If neither is selected, it would work as gnucash does now without trading accounts selected. So no one would be forced to use the new feature. Yes. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book-currency
On 04/07/2018 01:12, Alex Aycinena wrote: Today, in file->properties->Accounts tab, you can turn "trading accounts" on or off. Not really, you either use them or you don't. I propose to change this to a selection of three alternatives: use trading accounts, specify a 'book currency', or neither trading accounts nor book currency. If trading accounts is selected, it would work as implemented by Mike. If neither is selected, it would work as gnucash does now without trading accounts selected. So no one would be forced to use the new feature. Yikes, the extra option is scary. If 'book currency' is selected, it would require the specification of the book currency in file->properties. That is a substantial change. Transaction entry would be modified to ensure every split that was not in the book currency had a 'price' or 'exchange rate' associated with it (to the book currency). I am in opposition to this until it is explained well. In addition, the existing lot tracking capabilities would be used to track the 'cost' (in book currency) of all accounts not denominated in the book currency (lots would automatically be created rather than having the user go through the Actions->View Lots process). I object strongly as there is an extant means of balancing these tx. In entering any transaction that disposes of non-book-currency amounts, the user would be provided with assistance to calculate and book any gain or loss associated with the transaction based on these tracked costs. I object, this is leaning towards one jurisdiction. The idea is that several policies would be used for this purpose (probably implemented in phases): LIFO, FIFO, average cost (perhaps), manual specification. Much of this lot tracking has already been implemented but I don't believe it has been fully tested. I am supportive of this but don't think it has been thought through. A 'Cost and Unrealized Gains/Loss' report would be added to the menu if this feature is selected. It would show, for all non-book-currency accounts, as of a user-selected date: name, currency/commodity, cost, quantity, rate, value, unrealized gain/loss. Optionally, for each account, lot detail would be shown and, for each lot transaction detail would be shown. I think that is largely redundant. The US Income Tax Report would be enhanced to use the booked gains/losses (bug 554397). Or dropped entirely as being too country specific. Among the changes I foresee are: - File->Properties: specify and select 'book currency', if selected, default gain/loss account and default lot tracking policy. Doesn't the lot tracking happen regardless? - Account Edit: for 'non-book-currency' accounts, specify gain/loss account, lot tracking policy, short-sales allowed, currency account is priced in, skip lot-tracking flag. That is going to involve a lot of work. I'm think 2 or 3 years at least. - Register Transaction Entry: transaction currency will be 'Book Currency' rather than currency of register transaction is entered from, raise 'Edit Exchange Rates' dialog if split not in book currency, create/update lots for non-book-currency splits, if a sale (subject to 'short sales' rule), uses Lot Tracking Policy to calculate cost amount and tentative gain/loss That's realisable - Stock Split: make compliant - Lot Viewer: Modify existing capability so that integrity can't be messed up. Also, it should not be available in menu for book-currency accounts. It currently has a problem where it seems to generate multiple Realized Gain/Loss entries under some conditions I haven't figured out yet. It will probably take me several months to get this done. As I said above, I welcome feedback/comments. I think some agreement about what is wrong makes more sense. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book-currency
On 02/07/2018 18:02, Alex Aycinena wrote: I put it there for a project I am working on (but have gotten delayed on). It is not dead code; however, allow me to remove it in the next week or so and I will re-apply it later when the project moves forward. It seems better to remove it since we can't agree on what it means. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 28/02/2019 00:04, David Cousens wrote: 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. DavidC I like what you are doing a lot. Keep doing it. 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. Your use of words is good, "as I am able to". The point is we don't actually know where significant data is. That isn't a good thing for an accounting prog to know or not know. 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. Yes, the problem is the movement of significant files wasn't forewarned. I really don't know where some of my charity files are now! 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. True. I am not saying it should be. My argument is about data integrity and cohesion. It has no user structure to define authorization levels and no code to restrict access to specific functionality. I don't see why you are presenting this argument. While there is perhaps an ambition to move in this direction longer term, it is nowhere near there yet. Rinse and repeat. 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. I'm still using 2.4 are you sure the 2.8 message got out? It is possible I missed a message but a significant change in the reports should have caught my attention since I do have some knowledge about them. The place was identifiable relative to the book. 3.x changed that. To a place which is also identifiable relative to the book. Nope. 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. In principle, yes. 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 am not sure why you are arguing here if you don't understand that saved reports contain very specific account information and because of that are not transferable from one book to another. 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. Yes! The reports are useless if separated from the book! The question is this: who thought it was a good idea to separate the reports from the book? I think it was Geert but may be wrong. 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? Nope, the reports contain actual internal account references, my report won't work for you and vice versa because your accounts and my accounts have different internal references. Do you see why the placement of relevant files further away from the data makes less sense or not? Maybe someone is still on Geert's side? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 17:29, Geert Janssens wrote: Op zondag 24 februari 2019 16:23:24 CET schreef Wm via gnucash-devel: On 24/02/2019 01:06, David Carlson wrote: No, it is the name calling and digression from real subject matter. I had to do the name calling because no-one was paying attention. The more name calling you do the less I'm inclined to read though. I think I have read at most half of what you have written the last few days because I found the signal to noise ratio too low. Just so you know the effectiveness of your strategy... There are limited ways of approaching things if the other party won't listen. One can try the thoughtful approach. One can try being rude. If none of these work, what do you suggest? You're the person that is refusing to discuss what you have done wrong. What is a person meant to do? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 26/02/2019 08:28, David Cousens wrote: Wm and other interested parties To help alleviate the confusion over where user configuration information is located in V3.x cf v 2.6.x I have started adding some diagrams to illustrate the changes in locations that occurred which are hopefully a bit easier to understand than all that text. Currently I only have a Linux page up and running but I can build the others easily witha little cut and paste. I think this is a useful exercise and I'll contribute. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 26/02/2019 08:28, David Cousens wrote: Wm and other interested parties To help alleviate the confusion over where user configuration information is located in V3.x cf v 2.6.x I have started adding some diagrams to illustrate the changes in locations that occurred which are hopefully a bit easier to understand than all that text. Currently I only have a Linux page up and running but I can build the others easily witha little cut and paste. The Windows version is, I think, uncertain. Geert says he knows but doesn't. Some stuff is, quite simply, lost. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dormant Bugzilla Accounts
On 05/02/2019 15:55, Derek Atkins wrote: All accounts that touched any GnuCash bug were migrated over. The ONLY user data migrated were email address and full name. The user account passwords were NOT migrated because password data is not accessible (which is a GOOD THING). So all those accounts are, technically, in a dormant state. If those users would like to access them then they will need to perform a password reset on the account. Removing accounts is... challenging. The database requires them to remain in order to maintain proper history. Is there a problem with keeping the accounts around? I'm OK with Derek's answer, David T. Are you? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 16/03/2019 08:18, Colin Law wrote: I am taking from your lack of response as an indication of the fact that, having looked back at my posts, you have determined that I did not say anything that backs up your assertion. I now consider this matter closed. No, you should take my lack of response as me being bored with being blocked. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 15:40, Colin Law wrote: On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel wrote: That is the point, dear, you may not have said a swearword but what you are supporting is shameful. Please don't call me dear. That is almost as bad as labelling me a Trump supporter. I don't understand what it is you think I am supporting, all I am supporting here is gnucash and civility. If arguments were heard I'd agree. No-one likes repeating themself. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 07/03/2019 23:42, David Cousens wrote: 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. Devil's advocate: If (I am not wishing this on you, David, or anyone else, but it is not an unreasonable thing to think about if you are in Oz) flood or fire destroyed your home and your computer systems would you know what to restore? I think you don't or can't know what to restore wrt gnc at the moment. Making a backup plan is good but purposeless if there isn't a restore plan to match. re GNC_DATA_HOME and GNC_CINFIG_HOME you don't seem to have grasped that these are not consistent! At the risk of re-using stuff take a look at https://en.wikipedia.org/wiki/Fitch%27s_paradox_of_knowability In plain terms you may have a good back up strategy but have you tried putting it all back together? I think not, if only because the gnc bits will be all over the place. Will you have the latest version of all the files? Probably. Will you be able to put it together as it last was? Unlikely. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 08/03/2019 14:49, Derek Atkins wrote: Adrien Monteleone writes: Separating preferences for reports is, I suspect, more useful to a multi-user environment, which GnuCash does not support, but can be useful for a single user who keeps books for multiple entities that are all in the same jurisdiction and might well even use the same CPA. (and certainly have to file the same tax forms) They might even all follow a July-June fiscal year, for example. The whole options subsystem needs to be re-evaluated. I feel there are multiple categories: * Per-User * Per-User Per-Book * Per-Book I agree. Further, we are able to do this and have done it before, those with long memories may recall some things were moved (in a user sense) from Edit / Preferences (where they didn't belong) to File / Properties (where they sat more naturally) It might be useful for people to consider what belongs to the file? what belongs to me? is gnc an extension of me as a person? or is it a record of fact? I've said this before but gnc has a screwed up view of ownership when the prices.db (which is by definition impersonal) is included in the book but reports (which are intrinsic to the book, as in they contain actual id's that don't make sense anywhere else) are left all over the place. This includes things like the display features that you mentioned (which I snipped off). You're right, I feel that the column settings, and even whether to display placeholder and/or zero-balance accounts is probably a Per-User setting. Column settings I think of as per user. Placeholder ticks should be per book as gnc "does things wrong" if you enter tx at the placeholder level by accident and the account structure includes a mixture of commodities, currencies or anything else not the same. If all of the accounts below the placeholder are the same as the the placeholder account it works OK in my experience, but only in that case. I think of zero balance account display as a report setting. I think it would behoove us to go through every option, every preference, and every report option and decide which bucket they belong to. Indeed, many of the report options may need to be split into different categories, but I'm not exactly sure how to do that properly. I would be prepared to help with this as I would like to contribute and it seems like it will be years before my database and reporting skills will be utilised. I'm not convinced it's all about multi-user -- although part of it is. And for the record, GnuCash DOES support multiple sequential users. It just does not support multiple simultaneous users. Agreed. I think the multi-user argument is a red herring. The current structure is failing on all of same-user same-computer different-login same-user same-login different-computer same-book same-user different-login same-book same-user different-computer I could go on about all the combinations the 3.x structure simply does not support, hopefully those are enough for ordinary people to understand that what we have is fucked. multi-user isn't the problem to be solved, people understand if you say to them "gnc is like a spreadsheet, it doesn't work well if more than one person is changing it at once", it is damn hard to explain to them you don't know where their reports are! saying "gnc did it" doesn't work in my world view. I started a project to map out report preferences as part of a revamp of the tab content and I didn’t finish it. Perhaps completing that project will offer more insight. (and very likely allow me to discover that the present situation is optimal) I think this would still be a useful project, to map out all the various preferences and settings throughout the application. +1 I think we might need some people to change their ideas about what belongs to what before we can really progress. There isn't any point in defining stuff if it isn't going to be listened to or understood. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 07/03/2019 20:03, Adrien Monteleone wrote: Derek, I don’t disagree with your assessments of what certainly *can* (and maybe even, more often than not) be specific to a book rather than a user. I was thinking more along the lines of what someone *might* most likely want to carry over across multiple books. For example, I keep books for a few entities. Everything is in USD. (except for my personal book which has a smattering of left over currency from travels and some bullion I track as currency) I have no need for other currencies, and likely never will. At the least, I’d want to start books for a new entity, should one arise, with that same default currency in my reports. (simple enough since the default book currency is also the default report currency) But I might also like to never show zero balance amounts or the corresponding accounts, and I might like to always roll up the sub account totals into the parent (since I set all parents as placeholders) and *not* show any duplicative ’total’ lines. These were the types of settings I was thinking of that someone might want to carry over across all books and maybe even all reports. (where applicable) The same might very well applied to financial periods. Separating preferences for reports is, I suspect, more useful to a multi-user environment, which GnuCash does not support, but can be useful for a single user who keeps books for multiple entities that are all in the same jurisdiction and might well even use the same CPA. (and certainly have to file the same tax forms) They might even all follow a July-June fiscal year, for example. It might be that this is too small of a use case, and the user’s setup work so light that the development burden is simply not worth the effort. (and I’m by no means advocating for more work for the team already, I’m just chiming in with my own user story to consider.) I started a project to map out report preferences as part of a revamp of the tab content and I didn’t finish it. Perhaps completing that project will offer more insight. (and very likely allow me to discover that the present situation is optimal) If you're doing accounting for yourself and never plan to use a different computer or operating system, know how to make backups and are infallible (think about that list) the 3.x model is fine. OK, the infallibility is extreme but the 3.x file structure is just putting stuff all over the place without apparent thought. There are really simple answers to this, they presume === don't do what Microsoft told you to do === especially since they don't do it themselves in their own products. === No one in their right mind puts reports that depend on exact information in another file in personal file space *AND* expects things to work when any of so many things change. Another e.g. someone sets up a report, their PC has got a bit cluttered, they run a popular disk cleaner, result? Report is AWOL. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Transactions vs Splits
On 05/03/2019 12:57, David Cousens wrote: 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. Yes, it is possible but you have to be very careful when creating the export. i am working slowly and documenting everything i do so the developers have enough data to start identifying where the problems are. I am impressed at your attention to detail, D I think the problem is that once you've worked everything through in your beautifully crafted way you're going to reach the same conclusion as me. At that point you should make a mug of tea, swig a beer or whatever is appropriate and conclude, the gnc people haven't got it right yet. 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 OK, the documentation theory works in two ways: the document can say what happens or the document can say what might happen. We are free software so we can't do the latter, doing the former doesn't make sense either as it hasn't been done yet and may never be done. What do you put in the wiki, Mr David? If you are only exporting and importing transactions with 2 splits you should be able to get it to work. I can make it work with many splits but not many currencies or commodities I would create a dummy transaction first and export it, delete it in the book and then reimport it. NAUGHTY BOY! you *know* gnc can't do the round trip of export and import. It doesn't understand itself. 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. buglist ref please 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. If the test file I looked at earlier is an example, it is near perfect, I can see your thinking, actually, more importantly, I think other people can see your thinking. I'm not the important person because I'm looking at another problem that you may not have thought about yet. I do question documenting in such detail a problem that might change or not be there in a month or so, D. I'm more interested in structural stuff at the moment. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] budget.scm augmented to show ytd
On 03/03/2019 12:14, Christopher Lam wrote: for augmented budget report, which computes accumulated budget amounts instead of periodic budget amounts. https://github.com/christopherlam/gnucash/tree/maint-budget-refactor for the whole repo https://raw.githubusercontent.com/christopherlam/gnucash/maint-budget-refactor/gnucash/report/standard-reports/budget.scm for the report (which may require a recent maint build) adds a new option "YTD" which will display accumulated budget amounts (and also accumulated budget less actuals) the actuals remain period-specific. You're presuming budget.scm is a good start It *is* a good report, the problems are the code is overused in other reports the code presumes values that may not be true it is generally out of date unless you only have certain stuff -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] balance sheet review
balance-sheet.scm is a core accounting report in gnc, an essential in accounting as it allows the person presenting or viewing a report on a set of tx to show a full set of accounts or a subset. It generally does sums well. it is also core in that a number of other reports are built on top of it, i.e. if the basic balance sheet fails, the other reports fail too. if the basic balance sheet fails we have a systemic collapse because of over reliance on code people no longer understand. gnc has a second balance sheet (eguile on the menu) which is useful for auditing and similar uses but less useful for management reporting as the detail may be considered superfluous. balance-sheet.scm no longer understands the level of detail it was originally expected to understand wrt currencies and commodities. For emphasis: I don't say balance-sheet.scm is wrong, I love it and use it, I think it is a fantastic report; it just hasn't been maintained relative to the changing data it is reporting on ... the report no longer understands the inputs expected of it :( read from the bottom up of https://bugs.gnucash.org/show_bug.cgi?id=797046 for some incomplete details P.S. My political comment for today is that I think my own government consists of idiots that can't make up there minds, they're like children in a sand box. The EU is the teacher or parent watching and waiting until the children stop arguing and decide what they want to do next. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] CSV Import Format
On 01/03/2019 22:42, Geert Janssens wrote: Yes. The matcher should only be needed in the even more restricted case that no transfer account is set. In my experience the matcher is OK if you ignore it and understand the tx. You should just import it and fix it by hand, presuming the importer is wrong. Fact is gnc doesn't understand itself. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] CSV Import Format
On 01/03/2019 22:26, David Cousens wrote: 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 know I appear horrible here but I would like to read that poetry. 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 works for me. It would have been logical to do that first. I have also ignored trading accounts so far either. Trading accounts and importing are fine for me so long as you are specific. I am counting on that being largely dealt with if the multicurrency transactions work. Nope. The results so far are attached. ExportImportCurrencyTransaction.odt <http://gnucash.1415818.n4.nabble.com/file/t375329/ExportImportCurrencyTransaction.odt> I can see what you're thinking and it isn't going to work, sir. The round trip doesn't work. in plain words: gnc doesn't understand itself; there are some basics you need to know about munging, essentially gnc is generous in what it allows to be stored in a file via the UI (I think this is a mistake as it allows new lines in a file format that depends on new lines and so on) and it doesn't allow those chars back in. Now you know the round trip doesn't work, you know you need to fix a gnc file to make it gnc compatible ... which sounds weird but is true. I will continue and check out a multiline import to accounts with the same currency with 2 or more splits. I'm going over your work and I am impressed with your attention to detail. in 1.4.1 (c) you say "Set date format to d-m-y to match locale" I think that is a wrong thing to do, it is all about the file and the round trip. You also raise something that has been puzzling me, in your table under 1.4.1 (d) I don't know what a withdrawal or deposit is relative to. Surely gnc should understand debits and credits and plus and minus. I suppose it is possible someone will import tx to a CC or similar Liability account as the base for their finances but how likely is that? Don't most people start with "I have" rather than "I'm fucked, I owe so much I'm going to use gnc to see how bad it is". gnc people are generally positive, they're taking care of their finances. 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. I don't know. I can say the importer says it knows about commodities and doesn't. 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. I'll happily help with that. 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. Have fun, eat some food for me :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] CSV Import Format
On 01/03/2019 11:39, Geert Janssens wrote: I am aware multi-currency import is currently flawed. Having a detailed overview of what fails/what extra is needed will help a lot in setting this straight. Meneer, the import and multi currency are like the boy with his thumb in a dyke being asked to meet a lovely girl from africa. They look at each other, they like each other, but they have no way of communicating at the moment. === More seriously, Geert, and we have been through this before, what you need to do is a round trip. Export a set of tx, import a set of tx, do you end up with the same thing? gnc cannot do this yet. why does this matter? it means gnc doesn't understand itself, that is why it matters. === I know what happens next, I get personal emails I am honest -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] BackupGnuCash updated for GnuCash V3
On 27/02/2019 00:40, Chris Good wrote: Hi, I've updated my BackupGnuCash app to handle GnuCash V3 configuration files as well as V2. It can also backup the GnuCash Windows registry or the Linux dconf settings. The new BackupGnuCash version is 1.3.1. Please see: Linux: https://github.com/goodvibes2/BackupGnuCashLinux/tree/master/src/backupgnuca sh Windows: https://github.com/goodvibes2/BackupGnuCashWin/tree/master/src/backupgnucash Regards, Chris Good I love your confidence when you say === This includes among others a.The saved reports file, for example GNU/Linux /home/[USERNAME]/.local/share/gnucash/saved-reports-2.n Windows C:\Users\[USERNAME]\AppData\Roaming\GnuCash\saved-reports-2.n Note GnuCash 3 will use saved-reports-2.8 if it exists, otherwise saved-reports-2.4 but always writes to saved-reports-2.8. === If you are really confident about where gnc puts everything write the Good (<- yeah that was on purpose) script. I think you'll find you can't ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 01:50, Chris Good wrote: Chris, If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the reports are saved in /home//.local/share/gnucash/saved-reports-2.8 and I have verified this contains the report config which I saved. yay This is where I expected to find them based on the description in https://wiki.gnucash.org/wiki/Configuration_Locations. yay I am not sure what the 2.4 in your case and 2.8 in my case actually refer to. The wiki says they are related to GnuCash versions but not obviously the version which is running. 2.8 and 2.4 make no difference, wastrel :) Hi David, Geert answered this 6/6/2018: 2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a saved-reports-2.4, but it will only save to saved-reports-2.8. this is a spit mouth reply as it doesn't say *where* the report file will be saved. I expected more of you, ChrisG I haven't updated the wiki as it was recently changed to say: saved-reports-x.y presumably to ensure it doesn't quickly become outdated. Personally, I would prefer if it was more specific. I'm hoping I'll prevail or you or someone with some sense. I am finally about to release my BackupGnuCash java app 1.3.0, now updated for GnuCash 3. Scary stuff, brave you. As it is difficult to tell if a configuration file location has been overridden by an environment variable somewhere, I've taken the tack of only looking for configuration files to backup in the default locations. Regards, Chris Good May I have a look at your script? Love, Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 25/02/2019 06:52, David Cousens wrote: I admit freely I do not have a clear understanding of how the reports (and much else inside GnuCash) do work in detail and I doubt if I am alone in that apart from maybe the core development team. You are expected to be the foil for those that do know, sir :) GnuCash for whatever historical reasons is only sparsely documented which increases the difficulty of those of us with some development experience, but not long term on GnuCash, to contribute effectively. There is a big learning curve anytime you dig into the code. That is an understatement, the code is largely opaque comparative to the relatively simple transactions that occur. Having worked in development teams which had very limited resources in the past [snip] I hear you, I am not that boss here GnuCash doesn't have the luxury of a systems analysis team and management structure with oversight either. There is just a minimal team of unpaid developers, often wearing multiple hats, doing their best. Despite that it is far more flexible and adaptable than many programs which do have extensive development teams - hence the escapees from MYOB and Quicken where cost becomes a very significant factor. Hint: I am part of a systems analysis team and manage software. I just don't get used much. Since I know that I often find myself taking another view. Does gnc know where it took stuff from and placed it when 3.x was run for the first time? Looking at the code which did this, should answer this question. Not easily though, as the code generates scripts which perform the gconf->gsettings ,dconf migration (forced by the deprecation of g conf) as well as the changes in the settings location. some stuff got lost there, continue My brief excursion into it indicates that it is as described on the wiki Configuration Locations page. What was migrated is defined in /usr/local/share/gnucash/migratable-prefs.xml and processed by /usr/local/share/gnucash/make-prefs-migration-script.xsl to produce the gsettings from the original gconf settings. Wow! I admire your faith! problem is: the variables are just that, variable I don't think anyone knows where some of the details went My experience with the transition from 2.6.19 in my case to v3.0 was that I lost all of the training for the import matcher - no great problem, a couple of imports and it was largely back and that solved some historical import problems which were throwing up accounts which were no longer appropriate. There is some value in occasionally retraining the import matcher in any case. Your report is occasional not substantive. You will hopefully get a better report. The importer farts when I throw new stuff at it. Expected. I get by with the basic reports when i need them so i personally had no problems with reports, but I do appreciate that others may/did/do. I kept the 2.6 .gnucash preferences folder from 2.6.19 for some time after i migrated to 3.0in case I went back but unfortunately I decided around 3.3. that for my purposes things had become stable enough that i no longer needed to keep it. Uh oh If I remember correctly from looking at it at the time I had problems with the importer, what was in /home//.gnucash was moved to /home//.local/share/gnucash on Linux systems as described in the Wiki page on configuration locations. I am presuming this is also he case for Windows systems but I don't really use Windows so can't be sure. The problem with the gnc code for transition is that it placed no value on who accessed it first. This is slightly specious but if the cleaning lady accessed the file first she'd have all the reports in her private space on her phone forever! It is that weird. It is a lot more complicated than you think. Wm, 2.6 didn't store the saved reports with the book file either, it just stored them in a different location, so that is clearly not the problem. The place was identifiable relative to the book. 3.x changed that. What are the other changes that were introduced going from 2.6 to 3.x which are causing you problems now in backing up your files that didn't exist with 2.6? You are going to have to be specific if anyone is to diagnose and fix it. Other technical people already know. I'll bore you by saying some reports should be part of or very close to a "book". For the simple reason that (in the case of my charities for example) only the trustees are allowed to report on the accounts. I also agree completely that if a report configuration is tied to a specific book/set of accounts, i.e. it has been customised or otherwise been modified to be specific to that book, then its storage location should be with the data file. What defines this level of customisation for you and for me and any other user? Could GnuCash this on the basis of the configuration file contents perhaps decide where a particular report configuartion file should be l
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 17:18, Geert Janssens wrote: Op zondag 24 februari 2019 17:19:09 CET schreef Wm via gnucash-devel: Looks like you are now lying in public... (using your own conversation style here). Nothing gets deleted by the migration so there can't be data loss. We are talking well on the bug list, Geert. What you say is untrue, don't spoil the illusion until you know the details and truth of what can be lost. If the migration was actually triggered all files from DOT_GNUCASH_DIR have been *copied* to either GNC_DATA_HOME or GNC_CONFIG_HOME. You can look up the exact locations per platform on https://wiki.gnucash.org/wiki/ Configuration_Locations. The original files are still in DOT_GNUCASH_DIR. The problem is all of those VARIABLES were different for each person so we don't know where the bits and pieces of gnc have gone for everyone. I think this is an irrevocable error. If anyone is interested Geert and I are talking about this on the bug list in detail. This will, I think, turn out to be a mistake. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash maint: Multiple changes pushed
On 26/02/2019 11:56, Christopher Lam wrote: Hi Geert, Sharp eye indeed. I haven't used the new gnc:gui-error function because report.scm is being simulateously attacked: (1) refactoring in maint-scheme-progress (2) slowly creating nearly 100% coverage for tests (3) fixing an invalid code path introduced about 8 months ago, which was returning #f to signify failure for a report-definition-without-guid, when in reality the report-definition-without-guid was correctly handled by autogenerating guid. I considered gnc:gui-error to be a proper refactoring job belonging to (1) in my unpushed maint-scheme-progress branch but needed to create tests during (2) first to ensure the refactoring was safe, and the tests needed to handle non-gui code properly. I felt that completing (2) was more important than (1). But you're right, we could easily have used gnc:gui-error here. I love your confidence, Cristopher Lam. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 16:51, Geert Janssens wrote: Op zondag 24 februari 2019 12:54:35 CET schreef Wm via gnucash-devel: On 24/02/2019 02:25, David Cousens wrote: Wm, David, I appreciate your efforts as peacemaker, don't give up on all of us yet, most of us are trying to be good, promise :) If you draw a diagram from the information in the wiki page https://wiki.gnucash.org/wiki/Configuration_Locations where the meta data and report data is stored becomes fairly obvious and is fairly simple. I disagree, the user doesn't always know where their stuff is and therefore can't make a sensible backup. We (gnc) have a theory about where stuff should be but in practice it could be just about anywhere. My argument is that we should put important stuff near or approximate to the data it relates to rather than further away from it. There was considerable discussion in the forums at the time the changes were being made from 2.6 to 3.0. Not all views were heard. Taking a poll and not listening to the views that disagree with you is ordinary. This has ended up with me saying Geert (a person I respect enormously) may be a liar :( Sigh... Let it be clear the current thread is mixing up several discussions. 1. I agree (and always have) that certain data (like saved reports) is stored in the wrong place, namely in the metadata directory instead of in the gnucash data file. Near the data file is fine, it doesn't have to be inside it. the stored reports mechanism is imperfect but OK so long as we can keep a close association with the data the reports are reporting on. I'm not the only person that has noticed that stored reports are essentially useless when not associated with the data to which they belong. Are you unusually stupid in this regard? This has been historically so and hasn't changed between gnucash 2.6 and 3. Not true, there was a structural change between 2.x and 3.x The same data is still stored in locations reserved for application internal housekeeping (metadata). I'm listening to you trying to work out what you did wrong. 2. In the preparations to line up to gnucash 3 I decided to do some lower level housekeeping, namely to move everything that was *already stored* in the historical metadata/config directory ($HOME/.gnucash on linux) into present day recommended locations per platform ($HOME/.config/gnucash and $HOME/.local/share/gnucash on linux). I think that was unwise, let's continue. On MacOS this was already the case so nothing changed there. On windows the move was from $HOME/.gnucash to %APPDATA%\GnuCash, the default location on Windows *and* a request by several users that didn't like the .gnucash in their $HOME. Hmmmn, OK, you can make it my fault for not being strong enough in objecting. Is that what you want me to say? I honestly didn't believe gnc would do such a stupid thing. It was never my aim at that point to do the bigger cleanup of sorting out which stuff that was in separate metadata files should really be moved into the gnucash data file. But that is what happened and, I think, can't be undone now. https://bugs.gnucash.org/show_bug.cgi?id=797117 That's a completely different work that should still happen somewhere further down in the current big refactoring. I think it is too late. In further discussions, let's try to be clear please about what aspect is being discussed. I'd like you to address the bug, remember this all started with someone asking what to back up and no senior person from gnc having an answer. *you* put the metadata somewhere and *you* don't know where it is. shame on you. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 17:08, Geert Janssens wrote: You do like misinterpreting other peoples words to your benefit... Only if necessary. I have never seen you like this before. I never said it was a requirement to get gnc implemented on Windows. I said gnucash chose to better integrate with each platform. mixed words, no argument from me. The 2.x to 3.x changes affected all platforms I am aware of, see the start of the thread. And please re-read my other message. We're talking in different contexts. You continue to discuss on the level of what should be considered metadata and what should be part of the gnucash data itself. Are you saying my understanding of metadata is wrong? If so we can certainly discuss that in another thread. I'm only talking default metadata locations itself I've seen this before, you are narrowing the available space you might be responsible for. Doesn't work for me, Geert. as that's the only aspect in this context that has changed in gnucash 3.x. That some data should not be considered metadata is not under debate. We agree on that. Oh...kay help me to understand what you think is and isn't gnc's responsibility. You don't give a donder about reports, right? They're just occasional drek. It doesn't matter to you that someone took months getting a budget together and producing a report on that budget to satisfy their Trustees. You thought it was a good idea to just move a whole bunch of stuff to someone else's computer leaving no trace of the work behind. The thing that pisses me off is that you appear to be defending this harmful decision rather than apologizing. I have never in all my years of work with gnc seen you behave like this before, Geert, it seems to me you are running backwards faster than your legs will work. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 03:12, David Cousens wrote: Wm You could have a startup script which copied a common user config file for GnuCash from a backup or other central location to each users home directory and then copied it back on exit. On Linux the files would be those in the directories: /home//.local/share/gnucash (all user data) /home//.config/gnucash (gnucash config data) /home//.local/share/gtk-3.0(gtk data) /home//.config/gtk-3.0 (gtk config) On Windows they should be in c:\Users\\AppData\Local\GnuCash or c:\Users\\AppData\Local\gtk-3.0 OR c:\Users\\AppData\Roaming\GnuCash c:\Users\\AppData\Roaming\gtk-3.0 Don't know enough about Windoze anymore to know which set is most likely to be used but this link has an explanation https://www.makeuseof.com/tag/appdata-roaming-vs-local/ If you only wanted to back up the reports not just all user data, you could just backup the saved-reports-. from the requisite directories and just restore that file from a backup or other central copy stored with the main book file. It is a lot more complicated than you think. Let me open this part of the discussion by saying: Does gnc know where it took stuff from and placed it when 3.x was run for the first time? We know this was a one way change but were the from and to locations known about and recorded? I think they weren't all known about and recorded and gnc has contributed to actual data loss. <-- not something I ever wanted to say as this was warned about and avoidable. The warnings were ignored. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 01:06, David Carlson wrote: No, it is the name calling and digression from real subject matter. I had to do the name calling because no-one was paying attention. I'd prefer it if I was listened to the first time, promise. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 09:19, Colin Law wrote: On Sat, 23 Feb 2019 at 23:28, Wm via gnucash-devel wrote: ... You, Colin Law, seem to be the sort of person that votes for Trump because you aren't bothered if a black women gets shot. I fail to see what I have done to be so vilely abused as to be accused of being a Trump supporter or being a racist. If you are neither you have nothing to be afraid of. Also I fail to see what I said that so angered you. I merely expressed surprise that you use Gnucash when you have such a low opinion of the developers. How you can trust their work to look after your financial data when you consider them so incompetent I don't know. I have a good understanding of the tx gnc works on top of. As for my desire not to post words that may offend others then that is why I do it, so as not to offend. I have grandchildren and if they should happen to google my name and come up with my posts I would not want to be ashamed of what I have written. Some obviously are not worried about offending others. That is the point, dear, you may not have said a swearword but what you are supporting is shameful. I, unlike you, will have the pride of going to my grave honest and expressive. There aren't that many people like you out there, Colin Law, and you should let this community know which side you are on. Which side of what? Good accounting for people. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 08:44, Geert Janssens wrote: Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. Again it requires someone with time available and coding experience to implement it. Not really, 2. was better than 3. in this regard; let's just go back is my suggestion. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 08:44, Geert Janssens wrote: Completely agree in today's context. There have been reasons in the past it was done as it is. If someone has spare time and epxerience I gladly accept patches to fix this technical debt. There was nothing to fix in this regard in gnc 2.x gnc 3.x changed things, do *not* try and escape this, Geert! gnc 3.x made things worse not better in this regard. Understand? The fact that we even need a wiki page dedicated to file and configuration locations-- let alone one as long and convoluted as the one we have (and which needs additional diagramming)-- only underscores this problem. No, it underscores the dev team's willingness to be as open as possible about the complexities of a mature cross-platform application. Many applications store (meta)data is locations defined by the context. I know what you are saying, Geert, you are also wrong. The implementation of those concepts in gnc 3.x is a disaster for some, e.g I have charities that cannot use gnc 3.x I must ask again, because I do not want to shoot the messenger, who thought this change from 2.x to 3.x was a good idea? Who proposed it? Did the person that proposed it understand what they were suggesting meant for all people or just for themselves? This change is fundamentally wrong to what I understand the gnc ethos to be. People should have access to their own data, people should control their own data, people's data should be where they expect it to be. Geert, the way you are talking it sounds like you voted for Facebook. Go search for libreoffice's metadata for example, or firefox'. If you would want to document their metadata structures, you'd see something similar or even more complex. I know both those programs and know where they store stuff. You may recall I mentioned portableapps.com a while ago so don't be surprised /someone else knows about where other apps put stuff. In short, documenting metdata structures about gnc is mainly done. So shut up and do something useful, please. Part of the complexity comes from the multi-platform nature of gnucash. Each platform defines their own default locations for various kinds of data. And gnucash tries to apply these per platform. Geert: I think you just made another lie in pubic. The question is: should it? It is a lie that where to put files was an issue in getting gnc implemented on Windows. gnucash should be thinking for itself. if you go for the "each platform says where things should go" I will have access to your file and you will have access to mine in one years time. Try using your fucking brain for independent thought once! I want to be clear that I am truly grateful that Chris has decided to work on reports, and I have great respect for his ability to work with Scheme. I've yet to succeed in either editing an existing report or getting a third party report installed on my Mac. 13 years of futility on that front! Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. Again it requires someone with time available and coding experience to implement it. There is no person with coding experience available, get used to it. Move on. I also notice that I am being told to move on, who do you think is right or wrong, Geert? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 10:45, David T. via gnucash-devel wrote: Adrien, Using configuration files as a mechanism for working around the significant shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To be clear, I understand the challenges facing the team-- as well as accept that I am unable to effect change in these areas. Nevertheless, I am disinclined to paper over these shortcomings by accepting such workarounds. Furthermore, as I understand it, saved reports use the GUID of an account to refer to them, so any attempts at using a saved report from one file in another is likely doomed to fail. Yup. The transference is a specious argument. Whoever thought it was a good idea was, quite simply wrong, or, at the very least, doesn't or didn't understand how gnc's reports work. Or perhaps you're talking about settings associated with the standard reports? I profess I do not know how settings for these are stored-- although the fact that they are not stored with the actual saved reports (like the saved reports themselves) simply underscores the piecemeal mechanisms used for the reports. I've no clue about this future mechanism, I want the existing one to work. Your points about multiple user access are a red herring. Since Gnucash doesn't support multiple users, there's no point in speculating on how we might circumvent this limitation. Yay, David.T gets my vote! I have a lot of ideas about gnc being multiuser but I'm not suggesting they break what we have. Gnucash does, however, support one user having multiple data files, and in this case, a user opening file B will see all the (useless) saved reports for file A. Waves! Finally, the points originally raised regarding the scattershot storage of data that are integral to a set of books (whether reports, settings, or other data) remain. Get elected, David! :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 09:11, Geert Janssens wrote: Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens: Adrien, You beat me to it. I was about to also suggest making it a user preference to be able to store the report configurations either with the book or as a user location. Then the user could choose what suits their circumstances and configuration. David Cousens Well, for me each reference to "a new user preference" triggers the question "can't we solve it in another way". I don't think we can solve this easily, Geert. is there a way? Yes. Is there another way? Always. Is there a good or right way? Yes. For starters the user preference is an all or nothing thing, either all reports are in a book or in a common location. This simply is not true, Geert, I don't understand why you, who I respect so much, would say this when it is not true. That's not very fine-grained. Perhaps you consider some reports common and some reports book-specific. This could be solved by making it a per report option of course. Yes. It also doesn't solve the issue of sharing those common reports with other users (like your accountant). My accountant is me, I am also other people's accountant. I don't lie about money. To some extent Geert is making a jurisdictional argument, major commercial accounting applications are failing to provide what governments want. I think Reports / Tax Schedule etc should be removed for incompetence and trial balance reporting improved. And yet another issue: reports are only suitable for multiple books if these books have the exact same base as required per report. Yup, therefore it makes no sense for the reports to be stored per user. Do we know who came up with this stupid idea yet? take the transaction report. The user selects a set of transactions to display. Now suppose you select some accounts that are exclusively to this particular book. If you save this preset, and use it in another book that doesn't have these accounts there will be an issue. Geert, the saved report will most likely be useless with another book. Who was the fucking idiot that decided to use one set of saved reports? Tell us that, please! Be a man, Geert. I haven't tested, though at best the account is ignored, at worst the report throws errors. That's the best scenario. The other way around is worse: suppose you saved the report configuration with all asset accounts selected in one book. You then try to use this report on a book that has an additional asset account. As this account is not part of the initial selection it won't appear in the transaction report in the second book. Of course for a transaction report it's fairly easy to spot. There are other reports where this is much more subtle though. And this is not limited to account selections though I suspect that's the most important one. I'm seeing support for my concept, I like someone that thinks things through, eventually. So my conclusion is that report configurations are essentially book specific and should be treated as such to avoid unexpected accounting mistakes. Yes. On the other hand I understand it takes time to carefully configure reports to your preference and there's a wish to reuse this effort across books. That is easy, you just copy and paste a file. I have no time for cheap and lazy accountants that want to charge people lots of money for little work. I have done this thought exercise in the past. At that time the best I could come up with was to provide gui functions to manage report presets. In particular some form of import/export functionality. The configurations would remain per book. But one could explicitly export a configuration from one book and import it in another. My problem, Geert, is why you allowed what we have now to happen. Surely you, a respected person, a monitor, should have noticed it was wrong when the 2.x to 3.x code was settling in? I *did* talk about this! You (pural) ignored me at the time. It's not ideal as it doesn't solve the subtle errors issue. The user will still have to verify the imported configuration works for the book it's imported in. Improving on that will require smarter report options (like ways to specify "select all asset accounts" or "select all children from account xyz" instead of a dumb list of account ids). I'm pretty sure that would increase internal option complexity a lot and I'm not convinced the benefit in this case is worth the trouble. Geert, I don't get the complexity you're describing. If something ordinary that involves money happens in my life I add an account for that, this is how accounting is meant to work. You seem to think adding an account is something to be thought about by a panel of wise men and women, that isn't how modern accounting works. All brainstorming of course. No implementation in sight... Why no implementation change? The retro
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 04:05, David Cousens wrote: Adrien, You beat me to it. I was about to also suggest making it a user preference to be able to store the report configurations either with the book or as a user location. Then the user could choose what suits their circumstances and configuration. If the default was near or with the book I'd run with that. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 03:44, Adrien Monteleone wrote: One might want the same configuration in many respects and the same options on various reports to be ’saved’ (since there is no other way to accomplish this task) as user configured defaults to be useful across various books. Some people have separate files for many entities and they shouldn’t have to re-create all of that work for each one. You might always want to roll up child totals to the parent or not show zero balance accounts for example, regardless of the entity you are running reports for. Your accountant might always want to see reports following a certain format, different from the GnuCash defaults, regardless of the entity. But I also see the case where multiple users might access the same data file and you’d want them all to have the same configuration for the book options and a standard set of reports to be able to run. Certainly, there is room for improvement for a multi-user environment. (which GnuCash does not officially support at present from my understanding) Perhaps the user environment itself should be an option which would determine where the various configurations are stored. (or more likely, how they are stored, as they should probably all be located *with* the data file, though not necessarily a part of it.) Another option, specific to reports would be the ability to create a ‘custom default’ set of options. This would allow the creation of new books without having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd to some, but think of this more like a ’template’.) I think I understand "custom default" and it is not absurd. You are (I think) saying that a book / file / set of transactions / whatever should be associated with the reports that are particular to it. I also accept what you say about duplicating a configuration. That should just be a process of finding the right files, copying them to a new place and ... begin! We can't do that at the moment because someone decided to hide the important bits relative to a file and put them in a place that will be different for *every* person on *every* computer. If I was a conspiracy theorist I'd say someone at gnc HQ was not acting in the interest of the people. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 02:53, David T. via gnucash-devel wrote: While I take exception to Wm's tone and language, I agree with his overall assessment of the reports and configuration management. I am happy to apologize to you if someone eventually takes notice. I will do this by paying for a meal if we ever meet in person. Storing configuration data separately from the financial data and on a user (as opposed to a book) basis is questionable. Yup. Storing saved reports separately from the financial data and on a user basis makes no sense at all. A saved report for one file will be meaningless in another. This issue has come up many times on the lists. Yup. The fact that we even need a wiki page dedicated to file and configuration locations-- let alone one as long and convoluted as the one we have (and which needs additional diagramming)-- only underscores this problem. I don't think the person that wrote the page understood what they were describing. I am sure they were doing their best. I want to be clear that I am truly grateful that Chris has decided to work on reports, and I have great respect for his ability to work with Scheme. I've yet to succeed in either editing an existing report or getting a third party report installed on my Mac. 13 years of futility on that front! David T. I second that, the fact that a diminishing handful of people can read Scheme is interesting, it isn't a progressive language, the fact that gnc is dependent on it is regressive. I have made some small changes to a gnc Scheme report for my own purposes but when I put them forward for inclusion they were refused. Presumably because the person that needed to approve them didn't understand them. The thing I worked out was how to do "end of next month" and similar for reports. Sigh David, I am always unhappy if I upset someone, I often find myself in the situation of not knowing what else to do as no one listened the first time. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 24/02/2019 02:25, David Cousens wrote: Wm, David, I appreciate your efforts as peacemaker, don't give up on all of us yet, most of us are trying to be good, promise :) If you draw a diagram from the information in the wiki page https://wiki.gnucash.org/wiki/Configuration_Locations where the meta data and report data is stored becomes fairly obvious and is fairly simple. I disagree, the user doesn't always know where their stuff is and therefore can't make a sensible backup. We (gnc) have a theory about where stuff should be but in practice it could be just about anywhere. My argument is that we should put important stuff near or approximate to the data it relates to rather than further away from it. There was considerable discussion in the forums at the time the changes were being made from 2.6 to 3.0. Not all views were heard. Taking a poll and not listening to the views that disagree with you is ordinary. This has ended up with me saying Geert (a person I respect enormously) may be a liar :( Not all users had the same report startegy you were thinking of. Some users used the same report configurations with different books. That breaks if you have more than one book and those books have more than one set of customers (we're all customers of gnc now, right?). I think what you are saying is a tiny minority of self interested people overrode the real interest regarding where reports should be stored because it was convenient to them. If you (or anyone reading this) actually understands how gnc stores reports, how it saves them and where it saves them it makes no sense to put them in the weird general space that MS and other OS expect them to be in. Yah boo. Someone further up the chain than you or I believed something they were told and forgot about accounting. Going with the OS's recommendations has the advantage that your backup strategy may be more general than that for a single app. That means (yes, I am pushing buttons) you agree with the MS view that all your data is ours? Note it is the report configuration which is saved in the configuration locations not the report instance itself - that is in the book/main data file wrong, the report is not in the book/main data file. I am stating a fact, DavidC, you may believe it is there but it isn't and/or reconstructed from the data there when it is displayed. Nominally, yes. You are avoiding two important issues: 1. the report configuration file belongs to an account file; do you understand this? you can't apply my Balance Sheet report against your file and expect it to work, vice versa your Balance Sheet, we have different accounts! surely this is obvious? 2. the file / book / whatever doesn't know where the reports are, i have very good understanding of the formats involved and I'm telling you for free, your accounting data, as stored by gnc at present, has no fucking clue where anything else that you consider significant about it is stored. i.e. it is a fucking mess because one of the options available was for the file / book to know where it's meta data was. It is fairly simple to store a copy of user and configuarion locations contents with each data file if you really require the user and config data to be backed up along with the data file. It should be fairly simple but isn't. gnc has made a presumption about a user. if you are that user it will be OK, if you aren't you're fucked. David, keep going, please, if you think I'm bad read what I am actually saying. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 23/02/2019 23:09, David Carlson wrote: Obviously this is not worth reading Why? it is all about people presuming placement of significant personal, charitable and corporate assets and getting it wrong. Why is that not worth reading? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 23/02/2019 21:52, Colin Law wrote: I cannot understand why you keep using this software since it is so obviously horribly flawed and you have such a low opinion of the developers. I am sure you would be a much happier person if you used one of the many alternatives that are conveniently available. Surely anyone who keeps using it is just encouraging these ne'r do well developers to carry on in their recalcitrant ways and you really owe it to yourself to stop using it in order to show how disgusted you are. That'll show the F***Ts won't it. Let's examine your inability to say fuck and how that affects your accounting. You can check real sources (I don't do fake news, and you appear to be Trump fodder) or take it from me that people that swear or otherwise express themselves are generally happier than those that don't. You, Colin Law, appear to be the sort of person that would lie or cover up something if you saw it, I'm the other sort of person. That is why I like gnc, why do you use it? You, Colin Law, seem to be the sort of person that votes for Trump because you aren't bothered if a black women gets shot. There aren't that many people like you out there, Colin Law, and you should let this community know which side you are on. There are, in truth, very few developers and they are diminishing. It is possible the project could die. My data is safe because I understand accounting and can move on. Can you Colin Law? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 23/02/2019 21:52, Colin Law wrote: I cannot understand why you keep using this software since it is so obviously horribly flawed and you have such a low opinion of the developers. I am sure you would be a much happier person if you used one of the many alternatives that are conveniently available. Surely anyone who keeps using it is just encouraging these ne'r do well developers to carry on in their recalcitrant ways and you really owe it to yourself to stop using it in order to show how disgusted you are. That'll show the F***Ts won't it. Colin Dear Colin, I think you have actually said something stupid. Let's fight. You'll lose because you are wrong. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 23/02/2019 22:30, David Cousens wrote: Chris, If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the reports are saved in /home//.local/share/gnucash/saved-reports-2.8 and I have verified this contains the report config which I saved. This is where I expected to find them based on the description in https://wiki.gnucash.org/wiki/Configuration_Locations. I am not sure what the 2.4 in your case and 2.8 in my case actually refer to. The wiki says they are related to GnuCash versions but not obviously the version which is running. So if you want to back stuff up, what do you back up and are you sure you are backing up sufficient to replace or recreate in case of emergency. I can't do this for my charities because more than one person uses the book and I think this is what ChrisG was asking about at the start of this thread and what my general moan is. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 23/02/2019 21:52, Colin Law wrote: I cannot understand why you keep using this software since it is so obviously horribly flawed and you have such a low opinion of the developers. I am sure you would be a much happier person if you used one of the many alternatives that are conveniently available. Surely anyone who keeps using it is just encouraging these ne'r do well developers to carry on in their recalcitrant ways and you really owe it to yourself to stop using it in order to show how disgusted you are. That'll show the F***Ts won't it. Open projects don't work like that, so no. Love Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 10/02/2019 12:28, Geert Janssens wrote: FTR this code is not written by me. I'm merely reading how it currently works. good, because I am still angry at the plain stupidity regarding this implementation That aside, it will continue to work as long as the user uses a different name when copying the file or using File, Save As Doh! User has to behave badly to enforce good behavior by programme. The user *still* won't know where their fucking saved reports are unless they search for them! Possibly on someone else's computer in a network. Or maybe not available at all because they were using a shared laptop at a conference and now they're at home. HOW FUCKING STUPID IS THIS APPROACH? I honestly can't believe the brains we have available thought this was a good idea. Seriously, I DO NOT KNOW were reports are saved any more. WHO THE FUCK THOUGHT MYSTERY REPORTS WERE A GOOD IDEA OWN UP! WHO THOUGHT THIS WAS A GOOD IDEA? I AM SO ANGRY ABOUT THIS I WANT A NAME As there haven't been any complaints so far it looks that's what most people are doing anyway. liar, I protested in the user list (I do not call Geert a liar for nothing and expect him to be very angry with me in return for using that word about him but honesty must prevail) It is possible Geert didn't see the conversation where I complained about this in the user list but I think it unlikely. I think it would be useful if 2) above was changed so that a new book:id is generated. Shall I raise a bug? I don't know. As I said, if the file name is unique there's no need to rely on the GUID. It looks like it's fairly uncommon to want to use the same file name for books that are not related. Happens all the time when I'm debugging stuff. On the other hand I may also want to simply copy my existing book to a new location and happen to use File, Save As to do so. I don't think gnucash can make an assumption that either is right or wrong. You lose your reports and meta data when you do that. Is it your intention to lose them? At the moment you don't have the option. In itself I think it's too ambiguous/insignificant to create a bug report for it. I disagree, it makes consistent backups on networked systems near impossible. But on the other hand I also think this is something that we could analyze when we start revising our options/preferences system. On big aspect of this is evaluating for each setting whether it should be book specific (like book currency), computer specific (like saved window sizes) or user specific (like I have no example right now...). The metadata file is really meant to store computer specific data (though it currently does store more than that...). SO IF YOU WERE THINKING ABOUT THIS BEFORE WHY DID YOU MAKE SUCH A BAD DECISION?? As far as I know you didn't even ask people about this! What is a book option, what is metadata and so on *has* been discussed before and I am going to say *you* Geert are a liar if you think it was all new. I hate dishonest people. GR -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 08/02/2019 09:04, Chris Good wrote: -Original Message- From: Geert Janssens Sent: Wednesday, 6 June 2018 12:10 AM To: gnucash-devel@gnucash.org Cc: Chris Good Subject: Re: [GNC-dev] GnuCash 3 on Linux Op dinsdag 5 juni 2018 14:53:44 CEST schreef Chris Good: Hi, I'm working on my BackupGnuCash stand-alone app. I have 2 questions today: 1. I'm a little uncertain about where the saved reports and metadata files are in GnuCash 3.0 for Linux. I suspect they are by default: ~/.local/share/gnucash/saved-reports-2.4 2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a saved-reports-2.4, but it will only save to saved-reports-2.8. ~/.local/share/gnucash/books/[BOOK].gnucash.gcm Yes. Do note it can be [BOOK].gnucash_.gcm if you have several data files named [BOOK]. And the gnucash part in that file name is only there if the data file is called [BOOK].gnucash. Older versions of gnucash also allowed to save to files without extension or with the .xac extension. So it's really [BOOK-WITH-EXTENSION].gcm our elders and betters DID NOT THINK THIS THROUGH unless overridden by XDG_DATA_HOME. If you override XDG_DATA_HOME the files will be searched for and saved in $XDG_DATA_HOME/gnucash/ However this can be overridden even with GNC_DATA_HOME. If that's set, gnucash will search and save in $GNC_DATA_HOME (which may or may not end in "/gnucash" unlike the XDG_DATA_HOME to which gnucash will always append "/gnucash") basically you don't know where anything is, sailor. Hi Geert, Thanks very much for the above info. I'm afraid it has been quite a while since these emails but hopefully now I have a chance to follow up. I was surprised to learn about the part of [BOOK-WITH-EXTENSION].gcm as I have never seen this. I did some testing in Windows & Linux and I think I realise now how it works. you need to get the secret society part of gnc to document it then. There is a guid in both the main data file and the metadata .gcm files. For example, In main data file: fe06ec827c69b29977e25a7c6c090229 In .gcm: BookGuid=fe06ec827c69b29977e25a7c6c090229 So when the metadata is saved, GnuCash looks for (or creates) a .gcm file with a BookGuid matching book:id. It seems that when you create a new book by using File, New, the subsequently saved main data file has a new book guid created. However, if you create a new book by either: 1) manually copying a main data file to a different directory and/or filename Or 2) using File, Save As there is no new book:id created so both books will continue to use the same ..gcm file. Have you spotted the super simple "what files to backup" part yet? I'm not sure and I really ought to know. Actually I'm so unsure I'm leaving people on gnc 2.x because at least we know where stuff is. I suspect there may be people who may like to have different settings for different books but don't because they have created their new book by either of the 1) or 2) methods above. Don't confuse their little heads, they went with what the OS people said they should do. Obedience is good. As the book:id guid only appears once in my main data file, I assume it may be possible to correct this situation by: a) save the main data file uncompressed b) make a minor random(ish) change to the guid using a text editor (do NOT change the length of the guid) c) copy the old .gcm to a new .gcm (i.e. copy TEST.gnucash.gcm to TEST.gnucash_2.gcm) d) use a text editor to change the old guid to the new guid in the new .gcm That is all "don't do this unless you know what you are doing" and "don't do this at home" stuff. I'd like to document this in the wiki. Can you please let me know if I have made any errors in my above assumptions or forgotten anything important? I think it unlikely you will be allowed to wiki this because our idiots in charge made an executive decision that (for example) reports and books don't belong to each other! Seriously, they need not have a relationship. Even an invoice format (not something that belongs to each user) is now tucked away in each users private space making sensible and consistent backups near impossible. I'm still recovering from the strangeness of that decision and have never got a sensible answer back from anyone about why they actually did it. I think it would be useful if 2) above was changed so that a new book:id is generated. Shall I raise a bug? Go for it, bugs sometimes get listened to more than conversations. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 05/06/2018 15:09, Geert Janssens wrote: If you override XDG_DATA_HOME the files will be searched for and saved in $XDG_DATA_HOME/gnucash/ However this can be overridden even with GNC_DATA_HOME. If that's set, gnucash will search and save in $GNC_DATA_HOME (which may or may not end in "/gnucash" unlike the XDG_DATA_HOME to which gnucash will always append "/gnucash") it is just a messy breakfast spread across a table rather than on a plate, really nothing is in one place, nothing is where one might expect it. I am still very angry about this complete fuck up -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 3 on Linux
On 05/06/2018 13:53, Chris Good wrote: Hi, Hello, Chris I'm working on my BackupGnuCash stand-alone app. I have 2 questions today: read https://wiki.gnucash.org/wiki/Configuration_Locations and weep at how bad things have become The last time i addressed this our idiots in charge were so recalcitrant about even considering they'd done a stupid thing I stopped reading the gnc lists. I am glad you, someone I respect, have raised it again. 1. I'm a little uncertain about where the saved reports and metadata files are in GnuCash 3.0 for Linux. unfortunately the people that think they know better decided to put them where Micrsosoft, etc thought best. That means it changes at a whim, I am angry about this and they don't care. I cannot make a backup policy for my charitable organizations because our cleverer-than-thou FUCKWIT seniors just put stuff where they think MS or Linux policy suggests they should go and never actually think for themselves. The files should belong to the book and be closely associated with them. Our FUCKWITS IN CHARGE decided that the metadata belonged with the user not the book, that makes no fucking sense for an accounting file, they changed it anyway, gr I suspect they are by default: ~/.local/share/gnucash/saved-reports-2.4 ~/.local/share/gnucash/books/[BOOK].gnucash.gcm unless overridden by XDG_DATA_HOME. except you can't rely on those those locations. See the problem now? Can some-one please confirm? Only thing I can confirm is I don't know where anything is. 2. I tried to get version 3 on Linux (Ubuntu 16.04) running to test myself. that's the easy bit :) Thanks in advance, Waves back. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 02/02/2019 23:05, David Cousens wrote: I don't since I retired a few years ago, but I did for 8 years prior to retiring (and I used MYOB for the 10 years prior to that before escaping). I am certainly not alone. You could have a proviso that the script won't work for files using the business functions but that then detracts considerably from its usefulness as a general diagnostic tool. I'm respecting you more as we progress, DavidC. The broad point is that a normalization is without opinion or value. No person would know if you had run your business successfully or not. The fear is "the government will know I earned 20AUD on a contract and I didn't report". struth is your government has much larger issues to deal with, ask them to to pay attention to that. That is, if you can manage one government for more than 3 fucking months at a time! --- Point: MYOB is respected in Oz, Liz says so, it must be true. Rest of the world doesn't give a flying fuck about whether it is a good double accounting prog or not. --- Sqlite itself and its availability on Linux is not really an issue. Most distros have it in their software repositories. What may be more of an issue is that a lot of people who don't use the database backends because they don't want the additional hassles of learning to use and maintain databases may be reluctant to install it. True, I think this is also a red herring, most people are using Windows and SQLite comes with gnc for free. Shouldnt you be asking why more people aren't using what they already have? I'm retired. Disagree, your mind is still active :) Taking an extra half day to learn something new doesn't worry me as long as it happens before my time is up. But if I am running a busy lfe and/or a business as I used to, I would be more reluctant. Again not a show stopper, only a limitation on general applicability. David Cousens Have a hug. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] obfuscation script, windows/Perl SheBang
On 04/02/2019 17:03, Christian Stimming wrote: The script won't work on Windows anyway, at least not out of the box, because it not only needs a Perl installation including XML::DOM, but also some word list. On Linux this is available under /usr/share/dict/words (symlink to the default language's word list), but for windows some other choice has to be written into the obfuscate.pl script. Currently this isn't the case, so it will just complain about the missing word list. you know perl has a built in complain, I presume -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Perl SheBang
On 04/02/2019 15:32, John Ralls wrote: While we're on the topic of shebangs remember that they don't work on Windows. Remember too that running this obfuscate script on Windows will require the user to install perl. They might already have done so for Finance::Quote, but lots of users don't use F::Q. True, there are number of farmers that don't know why the person they voted for changed the price of their crops. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 03/02/2019 04:10, David Carlson wrote: OK, I want to try https://wiki.gnucash.org/wiki/ObfuscateScript but I am not a computer programmer. I have no clue how to use it. Can someone help me? it is perl, if you have F::Q working you probably have enough kit to run it. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecating ssh-dss keys on code
On 11/02/2019 21:32, Derek Atkins wrote: John Ralls writes: of dss keys appear to be owned by: asayed, chris, dvherman, hampton, jsled, linas, rolf, tomfray, wilddev, and myself. Derek, I think it makes more sense to remove the ids than to get new keys for any of those except you and maybe Linas. If any of them should wander back we can recreate the ids and generate new keys pretty quickly. Well, I figured out how to re-enable ssh-dss for now. I upgraded my own keys, but if any of the above (ex-?) devs want to have access going forward they will need to work with me to upgrade their keys. I will let the configuration modification lapse the next time that file gets reset by an update. Even if the script hadn't been lost it's likely not compatible with gitorious. Well, the script did all the user creation, email forwarding, etc. Then, yes, the key would need to be added to the gitolite admin repo too. Well, that was a fascinating insight into trust. Good thing the bad people don't read lists like this :) Motto: keep some people you trust in your trust model. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 10/02/2019 19:46, Alex Aycinena wrote: It is possible that Wm is noting a problem in gnucash that I'm trying to address with my 'Book Currency' enhancement (unfortunately, a bit delayed). I'm not antagonistic to your idea, Alex, just not sure I understand it. For most users who deal in a home currency most of the time and occasionally buy a foreign currency, say on a trip, and spend it on expenses, this deficiency won't show itself. Agree, we've a person in devel yelling about just that. But for people who deal in multiple currencies often, with complicated transactions, it may. Consider the following scenario: 1. A user is based in Europe and considers their home currency to be Euros following 2. The user uses Euros to buy multiple lots of GBPs at different times. The transactions each have different implicit exchange rates in the individual splits, but gnucash doesn't do any automatic lot tracking. I think I have to intervene and say Trading Accounts is your fairy godmother. If you aren't using them you are a silly boy, Alex. Some of the GBPs are used for expenses expressed in EURs. The splits associated with these expenses also have implicit exchange rates, but they don't have any relationship to the purchased GBP's costs unless the user makes carefull off-line calculations and enters the right amounts. I think that is a broken example. Small transactions are allowed to be discarded and joined into "we went out, bought a meal, had some some drinks with lovely people in a pub", I'm not a social media person (think it is all silly really) but don't have a problem with reality. I think Alex is wanting to track lots when he shouldn't. Alex: significant lots? sure; small amounts of spending? nope. trading accounts do this for free anyway. 3. The user then uses left-over GBPs to buy USDs. The split entered into gnucash has an implicit exchange rate of USDs to GBPs but nothing expressed in Euros. You and I my be agreeing on a problem that I have noticed in the TB regarding presumed valuations. If you want to run a report representing these transactions in Euros there is no way to do so unless you use an externally supplied exchange rate (e.g., from the price db) because the splits themselves don't have all the required information. Yes! I think you are a man so we will hug rather than kiss :) All: I think I may have insulted Alex by not reading everything he said before. It gets confusing sometimes. Alex: you are allowed to say I am an idiot or fool. If you want to run a report 'at cost', you also can't do this because item 3, above, doesn't contain the right information (so you have to 'fudge it' with an amount from the price db). This is wrong, the cost is yours or mine, an actual cost not a price.db cost for a remote commodity. I agree with Alex. This can be overcome procedurally in gnucash by using the trick of entering the #3 transaction in a register of an account denominated in Euros even if that account isn't involved in the transaction. Why would you do that? I am asking because I can't see the point. One split will sell the GBPs in EURs, the other will buy USDs in EURs and as soon as you hit the enter key, the transaction will 'disappear' from the register it was entered in (since neither of the splits were for that account). I wrote some stuff below and now I am asking, how do you get gnc to disappear splits? I am in favour of gnc keeping them. The transaction, however, will show up in the registers for the accounts involved and they will contain the implicit exchange rates that were missing above (but not necessarily with any lot tracking and still requiring a lot of off-line calculations to figure out the right numbers to enter into the splits). Alex: you said something important there. I'm sure I'm not fighting with you. Thinking: there is something significant in Alex's para above, I think I need to read it again. I may not reach the same conclusion but it would be stupid if I didn't understand. Now a report 'at cost' could be run, but only if the trick was used procedurally for every transaction not involving the home currency. Of course, this can't be assumed to be the case. I'm not convinced, if the report shows holdings in each commodity and currency and it works every time <-- it has to, there are some times pretending to be clever doesn't work, I think we are getting to that point with Alex's proposal. The 'book currency' feature is intended to deal with this by, if the 'book currency' feature is selected, forcing every non-book-currency split to be denominated in book-currency No! No! No! Don't be aggressive towards good accounting! (i.e., like the trick, above, but without having to use a third account register) you don't need to and enforcing lot tracking for each of these transactions (to get rid of all the off-line calculations), also superfluous (there are r
Re: [GNC-dev] book currency is what ... question mark
On 21/02/2019 21:47, Christian Kluge wrote: I’ve just seen that my final words I have to say to Wm haven’t reached the general public. Wrong, it is normally me that gets blocked not other people. I survive because I have residual project value. I’ve considered giving up on trying to make him understand how things are really handled. I am good at understanding, I say, again, you should try the user list. The dev list is different. Am 21.02.2019 um 15:51 schrieb Wm via gnucash-devel: On 20/02/2019 20:05, Christian Kluge wrote: Let me expand my example: Let’s say I’m doing someone else’s accounts and going through the liabilities first and see an invoice for 20 PLN. It just looks like an expense to me. My question is why is such a small amount a liability? Because it is automatically until paid. You clearly didn’t understand my example. You made it obscure. Probably on purpose, this whole exercise can't involve the ECB. Maybe it was agreed upon that every invoice will be recorded as liability regardless of its value or time of payment. I'm not sure I understand that. most invoices are liabilities until paid if you have an unusual arrangement then of course an invoice is still a liability until paid, that isn't a new accounting thing. if you are suggesting someone has given you unlimited credit my suggestion is that is unusual and you should stop doing any business with them immediately. "regardless of its value or time of payment" NOTE: the words above are very dangerous. it sounds like an open agreement to a short life to me unless you are in a country that has a well regulated financial system and are using it. I think you need to use the user list. the wild parts (regardless of value or time of payment) are unusual Then I don’t go through the bank statements first and try to find this transaction for the real value transferred but use the (monthly average) ECB quote. Why? If it is a single tx for such a small amount it is just an occasional expense. The ECB rate is immaterial You do *not* need the ECB rate for anything approximate to the price of a cheap restaurant meal. Seriously, Christian, is this really about you not understanding someone may have gone from Germany to Poland, bought some food and recorded the actual cost? Now you want the ECB rate? If it’s personal accounting I also don’t care. Even if it’s business related and just a one time thing. OK, I'm going to guess you are young and don't care about the rest of your life after this possible tx. But not if it becomes the norm. I never said that I talked just about one transaction that never happens again. Yeah, some people repeat their gangster errors I don't dislike you, Christian, I just think you're in the wrong place -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 12/02/2019 17:29, Alex Aycinena wrote: John - what you are saying is absolutely correct except for the part about working on it for three years. I did start it a while ago, but then other commitments have prevented me from working on it at all for a couple of years. The part you describe above will not be hard since the logic already exists; the integrated lot tracking, though, will be harder. I will shortly be able to get back to it though. Alex I think what Alex is proposing is detrimental to the project. It may (arguably) normalize bad accounting practice. As a moderately good citizen of the world [1] I object to what Alex is proposing without more clarity. [1] USA folks have lost your chance, you elected the idiot Trump -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 12/02/2019 17:29, Alex Aycinena wrote: -- Forwarded message -- From: John Ralls To: Wm Cc: gnucash-de...@lists.gnucash.org Bcc: Date: Mon, 11 Feb 2019 20:48:53 -0800 Subject: Re: [GNC-dev] book currency is what ... question mark On Feb 11, 2019, at 6:49 PM, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: at the risk of appearing to be an imperialist, what is "book currency" ? I think of "home currency" as whatever currency most people close to you (the reader) use to buy and sell ordinary stuff like carbohydrate staples (rice, bread, etc) and water in the UK that is GBP, in the USA it is USD, in most of Europe it is EUR, in other places, depending on government, it might be something else. my point is, unless your government is failing, you should be able to use the same currency for your home currency and your bookkeeping. presuming I haven't gone insane yet, does anyone know what a "book currency" is? If someone really wanted to run a set of accounts in another currency gnc isn't stopping them, the underlying transaction stream works perfectly regardless. Book currency is the currency of the book's root account, which you set when you created the book. For nearly everyone it is indeed their home currency, but that's immaterial to GnuCash. Suppose, though, that while your book currency is GBP, you have accounts in EUR and RUB and you do a transaction between those two. The transaction will set the transaction currency to the account whose register you use to create it and will balance the transaction in that currency: If you start in the RUB account then it will convert the EUR amount to a RUB value and check that the credit and debit values are equal. What Alex is working on is to instead use the book currency for balancing: GnuCash would in this example convert both RUB and EUR amounts to GBP values and balance the transaction in GBP. It's an interesting idea but I suspect that it will be very difficult to get right, a suspicion at least somewhat borne out by the fact that Alex has been working at it for at least 3 years. Regards, John Ralls John - what you are saying is absolutely correct except for the part about working on it for three years. I did start it a while ago, but then other commitments have prevented me from working on it at all for a couple of years. The part you describe above will not be hard since the logic already exists; the integrated lot tracking, though, will be harder. I will shortly be able to get back to it though. Alex I think this won't actually work. I can see the idea but at a tx level it is broken unless you take a view that everything is worth something in my home currency at that exact moment in time and never changes again. I think this is an absurd accounting view when fluid assets are available. I think Alex has thought things through from *his* POV and agree in general that a person should support their irrational thieving government, if my government payed me to lie I'd propose something similar. I am against what Alex proposes because it is so unclear what he intends. Alex: let us know what you mean, then we can progress. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Translation
On 20/02/2019 16:03, Frank H. Ellenberger wrote: I have also no problem with the Islamic perspective, which is the same as the medieval Christian view. I wasn't aware of that. Thank you for informing me. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 20/02/2019 20:05, Christian Kluge wrote: Am 20.02.2019 um 14:09 schrieb Wm via gnucash-devel: On 17/02/2019 19:50, Christian Kluge wrote: I think this should be in user not devel It might be your so called valuation exercise, but it annoys me very much that Finance::Quote doesn’t fetch the daily average quotes from the ECB yet. Any F::Q valuations should not affect your day to day life, I am well known for saying gnc is not suitable for trading. Governments generally don't care about one up or one down in decimal points for most people. Have I said anything about trading? Don’t try to interpret things. I know that the ECB rates are suitable for this case however they are a reference recording value. I am known to be rude to people that don't think well. I would like to point out that *you* made the first insult by saying "your so called valuation exercise". Who is the "we" and who is the "you" ? F::Q is an independent project. We love it and use it but we don't own it. Did you mean them or us? If you meant to speak to F::Q they have their own lists, go there if you have a problem with them. Often times with cash transactions it happens that people use simple exchange rates which are nowhere near the actual rates. So I might be paying 5 EUR for a service worth 20 PLN according to the receipt, so you might assume that the exchange rate is 1 to 4, but the actual rates are in a range of 1 to 4.2/4.3. My advice is to record the actual values, forget the theoretical exchange rate as you are unlikely to get it. So unless we’re talking about bank transfers or exchanging real currency there are situations where you’d want rates instead of the actual amounts exchanged. It seem stupid to me to account for what you wished rather than what happened. Did you eat 5EUR worth of some food or 20PLN of some food? The food has gone inside you and out by now :) Accounting is not a youtube thing, you don't value something afterwards unless it has residual value. Your poo is just that, your poo, no value in most currencies :) Let me expand my example: Let’s say I’m doing someone else’s accounts and going through the liabilities first and see an invoice for 20 PLN. OK, for other reader's reference, 20PLN approximates to GBP 4, USD 5 and a quarter and EUR 4.6, i.e. nothing significant in accounting terms, in fact nothing anyone else would notice in a personal or business set of accounts by itself. It just looks like an expense to me. My question is why is such a small amount a liability? Here is the point: it doesn't matter what the fucking ECB rate was! Do the accounting first! Is it a liability or an expense? Then I don’t go through the bank statements first and try to find this transaction for the real value transferred but use the (monthly average) ECB quote. Why? If it is a single tx for such a small amount it is just an occasional expense. The ECB rate is immaterial. I don’t know how it’s done in the UK but in the end a balance sheet has to be in Euro in Germany, so it has to be converted anyway. I agree with that, gnc's Balance Sheets and Income Statements are near perfect. If you have up to date prices around the beginning and ending of your reporting period in your prices db all should be well. You do *not* need the ECB rate for anything approximate to the price of a cheap restaurant meal. Seriously, Christian, is this really about you not understanding someone may have gone from Germany to Poland, bought some food and recorded the actual cost? Now you want the ECB rate? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
ightly, there are definite jurisdictional adaptations. The good ones are generalized, consider: there are only so many ways to add a tax to an invoice so let's generalize it, this is progress, gnc does this well and there are bad ones: Reports / Tax Schedule Report & TXF Export this means nothing to me, should it be removed? no; should it be put somewhere less prominent? yes. why should one country's tax filing be OK and another country's not be allowed? Some people have put some effort into tax filing in European (or soon to be ex-European) countries, the general report would probably cover 90% of the rest of the world. The gnc seniors don't see this. G! That unfortunately is not that easy. I found it very difficult to get to the point where I could even begin to develop any code. My wife (who was the daughter of a USMC second lieutenant) but was brought up in Australia is much tougher than I am on US cultural imperialism. Does she think of herself as an ex-pat or not? :) Unfortunately we are faced with governments being unnecessarily prescriptive about how things should be done in cases where they have minimal expertise. Making Tax Digital is a case in point in the UK. Yup, other countries too, but making the report can be made easier. I am hoping the ATO here does not catch a case of the HMRC bloody mindedness as we still have a fall back to a web portal into which we can cut and paste the required information. It gets worse in some places where you theoretically have to have been using approved software to be able to file a report :( -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Translation
On 20/02/2019 13:27, Frank H. Ellenberger wrote: We always suggest to create at first and submit https://wiki.gnucash.org/wiki/Translation#The_glossary_file which has also some explanation of the terms. While we got your fa.po, we never got a glossary/fa.po from you. I know you are using the translation project and there they are not common, but sometimes they are handy. :-) Frank, is this about eliding all references to debt or similar? There was another thread asking for references to mortgages to be removed. I don't have a problem with Islamic finance, it just seems silly to me to remove all references to it. If person doesn't like it they shouldn't use it, that is their choice. Denying the existence of borrowing costing money or similar seems bizarre. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] ECB Daily Average Quotes
On 18/02/2019 21:15, John Ralls wrote: On Feb 18, 2019, at 7:34 AM, Frank H. Ellenberger wrote: Yes https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html offers also several download formats Including an XML one, so it would be possible to write an F::Q module that retrieves the current day's XML file and extracts a currency rate. There's also a CSV download, but it would take some massaging to make it usable to be imported with the price csv importer. Sure, but you'd be left wondering "what am I going to do with these new numbers". -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] ECB Daily Average Quotes
On 18/02/2019 15:01, John Ralls wrote: On Feb 17, 2019, at 11:50 AM, Christian Kluge wrote: It might be your so called valuation exercise, but it annoys me very much that Finance::Quote doesn’t fetch the daily average quotes from the ECB yet. Are they published on a website somewhere in a way that a computer can digest them? Screen-scraping is OK, several of the F::Q modules do that, it's just fragile. For most people ECB rates are just something you use to say what you got, etc. It isn't realistically tradeable for most people outside of the futures, spread betting and similar markets. Let me put it this way, no matter how much you try to affect the ECB by buying or selling it, the ECB is probably just going to be the same anyway. HTH -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 18/02/2019 19:15, Christian Kluge wrote: There is one exception to this being VAT calculation. Sect 16 Par 6 of the German VAT act stats that foreign currency amounts should be converted with the monthly ECB averages or the actual daily rates. https://www.gesetze-im-internet.de/ustg_1980/__16.html Of course you’d record the full 5 EUR but a rate of 1 to 4.2 only 4.76 EUR would be subject to VAT. Herr Kluge, this is a user issue not a dev issue. Have a look at https://wiki.gnucash.org/wiki/Mailing_Lists and work out which list you should be posting to. Your english skills are good so I'd suggest https://lists.gnucash.org/mailman/listinfo/gnucash-user and https://lists.gnucash.org/mailman/listinfo/gnucash-de for de specific stuff. I notice in passing that we have language specific groups rather than political orientation groups, I think we might need .EU .USA .GB soon :( -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 17/02/2019 19:50, Christian Kluge wrote: Am 17.02.2019 um 19:58 schrieb Wm via gnucash-devel: On 15/02/2019 01:44, David Cousens wrote: If I start in Savings RUB , select the Savings EUR account and enter 100 it is assumed to be in RUB not EUR as GnuCash operates at present. This is clear, both registers are balanced and it is clear that they are correct. I am presuming what you would like is to be able to start in the Savings RUB register, select the Savings EUR account, enter 100.00 as the amount and have that interpreted as !00.00EUR, even though the register currency is RUB and then when you tab to the next line select Savings RUB have the currency dialog popup, enter or fetch the exchange rate, and then display the amount against the Savings RUB account in RUB. Nope. I normally know the exact amounts at either end of significant tx, the exchange rate is implied from the numbers. That *is* the right way of doing the accounting. You start with 100 of some currency and end up with 2300 of some other currency, the *valuation* is separate. What about the situations you don’t know the exact numbers or if you’re allowed to usage average exchange rates for tax accounting. The real amount exchanged doesn’t matter there/will be sorted out with correcting expense/income transaction. It is your (and my and everyone else's) personal responsibility to account correctly. You give an example below. It might be your so called valuation exercise, but it annoys me very much that Finance::Quote doesn’t fetch the daily average quotes from the ECB yet. Any F::Q valuations should not affect your day to day life, I am well known for saying gnc is not suitable for trading. Governments generally don't care about one up or one down in decimal points for most people. Often times with cash transactions it happens that people use simple exchange rates which are nowhere near the actual rates. So I might be paying 5 EUR for a service worth 20 PLN according to the receipt, so you might assume that the exchange rate is 1 to 4, but the actual rates are in a range of 1 to 4.2/4.3. My advice is to record the actual values, forget the theoretical exchange rate as you are unlikely to get it. So unless we’re talking about bank transfers or exchanging real currency there are situations where you’d want rates instead of the actual amounts exchanged. It seem stupid to me to account for what you wished rather than what happened. Did you eat 5EUR worth of some food or 20PLN of some food? The food has gone inside you and out by now :) Accounting is not a youtube thing, you don't value something afterwards unless it has residual value. Your poo is just that, your poo, no value in most currencies :) I also wanted to add that the bug with not being able to see the currency exchange rates in the price list also effects me running 3.4 with the sqlite backend. Most of that is fixed in the test version I am using. There is a small bug left over if you need to change a price after it has been fetched. https://bugs.gnucash.org/show_bug.cgi?id=797046 for reference I can however add the rates to the list and they’re used in transactions and listed on balance sheets if requested. That is normal service :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 15/02/2019 01:44, David Cousens wrote: I haven't read all the recent list replies yet but I think this sort of thing If the book currency is USD (or AUD or any other third currency) then the currency conversion becomes EUR<->USD<->RUB. The double conversions involved to the EUR and RUB may introduce scope for rounding errors to produce slightly different results on conversion back. It also assumes that EUR->USD-> RUB will give the same result as EUR->RUB. Where the exchange rates are good to 6 significant figures, this appears to be OK using today's figures (https://www.xe.com/currencyconverter): 1 EUR=75.3052 roubles 1 EUR =1.12958 USD 1 USD = 66.6667 RUB => 1 EUR = 75.3054 RUB. is certainly part of the reason why the TB is going wrong. Congratulations on your prescience :) add yourself to https://bugs.gnucash.org/show_bug.cgi?id=797097 if you're really interested. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] book currency is what ... question mark
On 15/02/2019 01:44, David Cousens wrote: Wm, My apologies for being long winded in the following, but I think it is necessary to achieve clarity in what is proposed or intended. Not at all, I appreciate your effort and have read what you have written more than once. The "book currency" is the currency assigned as the default currency, i.e the currency of the root account, when you create a new book or file using the File->New File. I can create a new file with a default currency of USD even though my "home currency" i.e. the currency where I live, is AUD and I may choose maintain a separate book or file with AUD as its root or default currency. I can't think of a good reason why unless I happen to commute between the US and Oz on a regular basis but I could choose to do it. When you create a new account, it will by default have that "book currency" unless you change it to another currency. Starting a tx stream with an unadorned (no currency) number is normal for most people, changing it part way through is never going to be simple. Obvious answer? Start with a nominal currency tx. 1 [nothing] = 1 [Currency of Choice] it really can be that simple, put that right at the beginning and every unassigned number has a currency. In what way do you think what John said is invalid? I don't really disagree with John much, he is just often the person brave enough to reply. For a transaction crediting an account in RUB and debiting one in EUR for 100 EUR at an exchange rate of iEUR=75.30 RUB(e.g. asset saving) the register for Savings EUR appears as Debit Credit Savings EUR 100.00 Savings RUB 100.00 and the register for Savings RUB as Savings EUR7530.00 Savings RUB 7530.00 when the transaction is carried out from the Savings EUR register (with presumably the description field linking the two to show they are one and the same transaction. Ummm, have you heard of Trading Accounts? The splits show actual values for each register. If it is initiated from the Savings RUB account the transactions appear exactly as above in each register (provided of course the same exchange rate is used. The advantage of the above for me is that the value of the transaction in each currency is clear and the exchange rate used is clear and calculable from the balances (as well as being able to check the price editor.) and it is clear that the transaction is balanced in both currencies. Trading Accounts, again. Plus, I find it useful to right click and choose Edit Exchange Rate if I want to check (the tx rate not the price file rate should be prime) [1] If I start in Savings RUB , select the Savings EUR account and enter 100 it is assumed to be in RUB not EUR as GnuCash operates at present. This is clear, both registers are balanced and it is clear that they are correct. I am presuming what you would like is to be able to start in the Savings RUB register, select the Savings EUR account, enter 100.00 as the amount and have that interpreted as !00.00EUR, even though the register currency is RUB and then when you tab to the next line select Savings RUB have the currency dialog popup, enter or fetch the exchange rate, and then display the amount against the Savings RUB account in RUB. Nope. I normally know the exact amounts at either end of significant tx, the exchange rate is implied from the numbers. That *is* the right way of doing the accounting. You start with 100 of some currency and end up with 2300 of some other currency, the *valuation* is separate. gnc doesn't seem to get into this muddle with other commodities, btw, just currencies. aside: There may be occasions when an approximate value may work fine because the amount doesn't matter but commercial exchange rates as fetched from AV or taken from a bank or credit card statement for example will rarely match an actual tx for most people so one should never start from there. And similarly if you start in Savings EUR and repeat the procedure. I.e. no matter what register is in use, the register would display the amount of a split in the currency of the account that the split is being made to not the currency of the register . e.g. would appear in the entries for both registers Debit Credit Savings EUR 100.00 (EUR) Savings RUB 7530.00 (RUB) I personally would be quite happy if this were the way GnuCash registers behaved, particularly if the currency symbol were to appear at the end of each line to indicate the currency applicable to the split, but I find the current system of displaying amounts in the currency of the register being displayed, equally as clear. When I made my first multicurrency transaction, it took m
Re: [GNC-dev] book currency is what ... question mark
On 12/02/2019 04:48, John Ralls wrote: On Feb 11, 2019, at 6:49 PM, Wm via gnucash-devel wrote: at the risk of appearing to be an imperialist, what is "book currency" ? I think of "home currency" as whatever currency most people close to you (the reader) use to buy and sell ordinary stuff like carbohydrate staples (rice, bread, etc) and water in the UK that is GBP, in the USA it is USD, in most of Europe it is EUR, in other places, depending on government, it might be something else. my point is, unless your government is failing, you should be able to use the same currency for your home currency and your bookkeeping. presuming I haven't gone insane yet, does anyone know what a "book currency" is? If someone really wanted to run a set of accounts in another currency gnc isn't stopping them, the underlying transaction stream works perfectly regardless. Book currency is the currency of the book's root account, which you set when you created the book. For nearly everyone it is indeed their home currency, but that's immaterial to GnuCash. OK I'll think about that. Thought about it. Invalid. The value is the same. Ummm, JohnR I should not be beating you up on simple stuff like this. Suppose, though, that while your book currency is GBP, you have accounts in EUR and RUB and you do a transaction between those two. The transaction will set the transaction currency to the account whose register you use to create it and will balance the transaction in that currency: I don't think it does or should, I just want the tx recorded naturally, I think John Ralls is a mildly naughty man making a point to a slightly younger man about an obscure point. consider if the book should record ordinary numbers and currency What do other people expect? If you start in the RUB account then it will convert the EUR amount to a RUB value and check that the credit and debit values are equal. it may for *some* value of equal. IT OFTEN GETS IT WRONG BECAUSE YOU DUMB AMERICANS DON'T UNDERSTAND ANYTHING OTHER THAN USD Since I have GBP, EUR and RUB it is ordinary for me to experience exchanges rates but I think my point stands, gnc isn't doing the sums right. What Alex is working on is to instead use the book currency for balancing: GnuCash would in this example convert both RUB and EUR amounts to GBP values and balance the transaction in GBP. It's an interesting idea but I suspect that it will be very difficult to get right, Wouldn't that mean a book for each currency? Umm, it is a nice idea and may work for some exchanges but near impossible for me a suspicion at least somewhat borne out by the fact that Alex has been working at it for at least 3 years. Indeed. I think the main problem will be getting more than one book to work together as one. Easy if you know how. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] book currency is what ... question mark
at the risk of appearing to be an imperialist, what is "book currency" ? I think of "home currency" as whatever currency most people close to you (the reader) use to buy and sell ordinary stuff like carbohydrate staples (rice, bread, etc) and water in the UK that is GBP, in the USA it is USD, in most of Europe it is EUR, in other places, depending on government, it might be something else. my point is, unless your government is failing, you should be able to use the same currency for your home currency and your bookkeeping. presuming I haven't gone insane yet, does anyone know what a "book currency" is? If someone really wanted to run a set of accounts in another currency gnc isn't stopping them, the underlying transaction stream works perfectly regardless. Curious minds, etc. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 11/02/2019 17:30, Adrien Monteleone wrote: Please tell me the intent is to *add* the book currency value, not replace the actual currency value. Our USA friends are still thinking about what a TB is for. I would hope that the actual currency transaction data would still be available. > The actual transaction values should be prime in a TB. If you have to reconcile against statements or receipts (or suffer an audit) with foreign amounts sans their ‘book currency’ equivalents, such original data would be critical. Agreed, you know how much the tx was for, your audit should agree. A trial balance should never be speculative (unless you voted for Trump in which case buying shares in jewish orientated russian biased golf clubs that own wall building companies would seem a good idea). Please check if your financial adviser is qualified before taking their advice and it is with regret that I mention Judaism, Trump's son in law is a nasty person regardless of religion. If so, this is how I originally conceived GC was operating till I learned otherwise. Shrug, where do we learn more about "book currency". ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 11/02/2019 04:03, David Carlson wrote: Wm, before you run off at the mouth with all your innuendos, look at facts. I'm hoping you get a message from Liz If you don't there is something rotten in this list's administration. Did you try running a test on one of your backups from around June 2016 using Gnucash 2.6.12 or earlier? No. Why? Because I own a transaction stream. Watermelon. My transaction stream is the same regardless of how it is interpreted. Golf ball. I think that if you do you will find that the Trial Balance Report is correct if you scrupulously check the settings to use the Average Price valuation method and check your price database to be sure that the transaction generated prices are present. you may be a person of high IQ in your local community. you don't understand a trial balance. John Ralls alluded to that earlier today. JohnR isn't saying the same thing to me and you, Trump voter. In fact, I bet yay, how much are you prepared to bet, you piece of shit? My estimate is that you will bet fuck all because you are wrong. You are just a noisy person. > you could try re-running the Trial Balance Report in release 3.4 on a current data file using the Average Balance method of valuation. There is no point, the valuation approach is wrong. There was a period when GnuCash was not entering transaction generated prices into the price database as Alex noted, but that was corrected some time ago and recent prices from recent transactions are all entered in the price database. The price db has FUCK ALL to do with the TB > Granted, it will be difficult to find many of those old missing transaction generated prices that involve the base currency but maybe they might get added back by using the trading accounts feature. I have not tried that, but it might be worth a try. You don't appear to have a clue what the issue is. As Alex suggested, transactions that do not involve the base currency would need to be dealt with some other way. David Carlson Do *not* invoke other people without their permission in future, David Carlson I *know* I get Liz angry but you have broken all the rules regarding good manners by being an actual liar. That is not easily forgiven. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing/obfuscating live data
On 04/02/2019 08:40, Christian Stimming wrote: In a real data file there are still more places with text that need to be modified, e.g. the scheduled transaction templates, bayes import matching, and such. Also, the dates are left unmodified which may or may not be a problem. Stripping out scheduled tx should be OK unless they are specific to the problem being reported. Because gnc is, by definition, a tx stream processor future tx are not normally noticed until encountered. (Personally I love the ability to generate tx in the future, it allows me to model my immediate monetary future. A very positive thing.) I think all of the import stuff should be stripped too. Dates are more interesting, Christian people (right or wrong) place value on dates (in my culture it will be 14 Feb soon) How about this as a proposal? If the dates in the file are in sequence it usually won't matter how much time is in between each date. Why do I say this? Because gnc is a *sequential* tx processor and as such the *sequence* of transactions can be important but the actual dates often aren't. If anyone is struggling with this conceptually, in a gnc file the date defines the order in which a tx is processed, that is what a transaction stream program does. The tx may be in the wrong order (this is part of the reason why gnc does the weird thing of loading everything into memory, it can't trust the file!) so it has to work out which tx is first, which one comes next and so on. I don't think I am teaching ChristianS anything, just explaining stuff. So, I think the dates can be modified so long as the *order* of dates and times is left extant. Proposal: make the first date random (after 1971 or some later date for technical reasons), treat the tx in date+time sequence adding one day each time a difference is noted. This will produce a time compressed file that obfuscates when someone actually did something. Thoughts? -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 03/02/2019 16:03, John Ralls wrote: On Feb 2, 2019, at 8:10 PM, David Carlson wrote: OK, I want to try https://wiki.gnucash.org/wiki/ObfuscateScript but I am not a computer programmer. I have no clue how to use it. Can someone help me? Run it from a command line using perl, assuming here that you have Strawberry installed on C: c:\strawberry\perl\bin\perl.exe ObfuscateScript path/to/myfile.gnucash Note that it rewrites the file in place, so make a copy and run it on that. The file needs to be uncompressed. Apart from the write in place I quite like it as an idea to progress thought. Positive: it is in perl which (many|most) people may have a working version of if they are using F::Q Negative: it doesn't reconcile well, but this may actually be a positive because ... Positive: if the script breaks some splits this should be seen as a good thing by some, it makes the work of the super secret agents running gnc harder. Thinking aloud: another way of normalizing would be to split to some point beyond usefulness and let gnc put it back together again using Actions / Check & Repair === Remember flox, the idea is a file that someone else (who probably didn't vote for the idiot Trump) could look at to see *your* problem. Does the remote person want to see you paid USD10 for a burger meal and some beer then vomited on the pavement and had to pay a fine for that? Nope. The remote person wants to see what the fuck you have put in your file that is screwing up the transaction stream. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 03/02/2019 02:01, David Cousens wrote: As Geert pointed out whole of program testing is very difficult and rapidly reaches a situation where complexity is equal to or greater than the program complexity and this is really what gave rise to unit testing where you test individual components which do a specific function. That can't fix a problem where an incorrect presumption was made in the first place. One area in which an example file rather than a test file might be useful is in developing the documentation. The guide section on Accounts Transaction following through to Personal Finances in escence constructs a simple file while doing the tutorial. Here though it is the process of constructing the data in the file that is useful. A completed example file is not of great use. I'd advise against using any file as the right file for documentation purposes. There are just too many edge cases. Something I think would be amusing rather than instructive would be to put all of the example tx in the docs into one file. I doubt it would be useful to anyone other than an historian of finance programs but it would be fun to see what we ended up with. If someone is thinking of presenting a paper at a conference try it, mention me if you are feeling generous :) It is also likely that most problems which are likely to require this depth of investigation are unlikely to show up in a test file unless you can execute a series of entries in a scripted manner i.e. interact with the gui from a script and this is not possible with GnuCash at the moment AFAIK. The problem is usually somewhere in the process of getting to the results in the file and what is in the file is merely a symptom of the problem. gnc is a transaction stream application. each time you open a file it starts from 0 and does addition and subtraction. no more no less. on top of that we have pretty stuff, convenient ways of adding new transactions to the stream, convenient ways of reporting the results of the stream. nevertheless, it is still just a program interpreting a stream of transactions. gnc is a convenience. I don't see why I should have to give live data to people I don't know in person ... and I don't even have super secret stuff like tax havens or a Donald Trump blow job account or a religious belief. I just feel uncomfortable showing ordinary tx to people I don't know, it is that simple to me. Q: Why does someone need to see *my* (or your) tx to fix a problem? A: they don't So, we are stuck. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 09/02/2019 13:03, D via gnucash-devel wrote: That sounds to me like it's using a different exchange rate from one day to another, and I'd agree with your assessment in that case. I would have thought that the exchange rate in the transaction would be used. You are correct. I have an amount of something (shares, foreign currency, whatever) worth (nominally) what I paid for it. Mind you, I can't wrap my head around the subtleties that seem to apply on this report. There should not be any subtleties in a TB, it is an internal document not a public facing one, the tax people don't ask for your trial balance in any place I know unless they think you are bad person in the first place. If I don't buy or sell some of whatever it is, I just have what I have for TB purposes. If I want to place a value on whatever I put a price in the price database on a date and use a Balance Sheet report. The TB is about *actual* tx not values at some putative point in time later. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 10/02/2019 22:52, David Carlson wrote: Wm, Where does unrealized income fall into tb if there is no price in the database on the closing date for one or more security or currency accounts because it was not sold? Essentially it doesn't occur, it is just a number of something if you aren't using Trading Accounts. The TB isn't about the *value* of stuff, it is about what you paid for it at a time and how much of it you have at a point in time or over a point in time. The Balance Sheet is about the value of stuff at a point in time. The Income Statement is about how you got to a value over a specific period of time. The TB is worthless or pointless if it "double dips" into either of those major reports remits. === Consider this tx 2010-01-01 Assets:Cash -100 Assets:XYZa +100 Cash is real money in your home currency XYZa is an unlisted investment What your TB should show wrt XYZa is that you have 100 home currency units (usually called money) worth of it. That never changes unless something else happens. Consider this tx 2010-01-01 Assets:Cash -100 Assets:XYZa +4 shares @ 25 each Unless someone else is buying and selling those XYZa shares they are only worth what you paid for them at best, your TB should reflect that you have 4 XYZa shares not guess what their value is. Am I explaining this well or not? The Balance Sheet allows you to put a value on stuff The Income Statement says how you got there The Trial Balance should say what you actually have and what actually happened rather than what you think you have and would like to have happened. Why? Because it is good accounting. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Further feedback
On 09/02/2019 04:05, Christopher Lam wrote: Well I've been schooled. Please refresh and try again. The headers should match the desired report *post* reconciliation. The transactions reported are: uncleared, cleared, and reconciliation whereby split-reconciliation-date = account's last-reconciliation-date. Ummm, ChristopherL why are you being nice to the fool? I can think of other stuff you could be doing! -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 10/02/2019 12:40, David Carlson wrote: Lets all step back a second and consider what the report is supposed to show before deciding whether it is always correct. I think the report is conceptually broken. The report is supposed to cover all of the assets and liabilities that were selected when configured only over time interval which was also selected during the configuration. It doesn't do that as far as I can tell. It is supposed to use a method of valuation for accounts not in the base currency which is also selected during the report configuration. It doesn't do that, actually. My reading of the code (and I am an acknowledged fool when it comes to scheme) is that it uses a balance sheet type approach rather than a p+l type approach to time. If I am right then the report is wrong to begin with, because a trial balance can be for either, a P+L type report (i.e. tx from begin date to end date) OR for a Balance Sheet type report (i.e. start at the beginning up to a point, what have we got?) Over the last several years there have been a number of discussions about whether the various valuation methods work correctly, with respect to report dates vs dates available in the data file and even whether the values should be displayed or calculated with exact i.e. fractional numbers or in floating point. All of that is in the infrastructure, not in the actual report code. That is incorrect. A trial balance is a report, it shouldn't be doing valuations at all *except* right at the end, maybe. If it is going to do valuations they should be presented separately from the account balances. Remember flox, at trial balance (and it can be from any date to any date) you have something like 100 in your own currency 1 in your fantasy currency 10 shares (or similar) in investment A 11 units (or similar) in investment B etc *that* is what a trial balance should report, the *money* value of investment A, Investment B and the fantasy currency is what the Balance Sheet, etc is for, the TB is a different animal. I believe there were some code changes implemented over the life of the 2.6 code series, and there were more changes in the transition to 3.x. I don't think we're getting anywhere (I have read the bug thread) I think the bottom line is that yes, different code releases will give different results with some data even if the report configurations are scrupulously checked to be identical. That's scary. Now, where do we want to go from here? I think we need a new TB. The problem is it can't be implemented however good it is because we're stuck with Scheme reports. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 10/02/2019 16:54, John Ralls wrote: The "Average Cost" price source creates a price based on the actual transaction prices and is designed for the TB report, see the thread beginning with https://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023297.html. I broke it for 2.6.13-2.6.21, see https://bugs.gnucash.org/show_bug.cgi?id=775368. The "Average Cost" and note that even 2.6.21 didn't fully fix it; that didn't happen until 3.2. Average cost is the *only* price source that works for the Trial Balance Report. In particular the "Nearest in Time" and "Most Recent" sources will take prices from the price database that are unlikely to reflect the actual prices for the transactions and will vary depending on the date of the report. I agree with Adrien that we should consider removing the price source option from that report and hard-wire it to average cost. > Why average cost? A TB should use actual numbers. We are meant to be checking what happened rather than the value of what happened. There are separate reports for that, we call them the Balance Sheet, Equity Statement, Income Statement and similar. The TB is internal. At the risk of pushing too much burden onto you, JohnR, for which I apologise, I'm not at all sure gnc's TB should be there as it stands *unless* one rarely uses commodities of any sort. If you're a home currency only person that thinks stock markets are the devil's own work it will probably be good enough. Otherwise I think it is time we said, not fit for purpose. The logical problem for me is that the SQL is so simple and the Scheme involved in a new report when it is being deprecated is largely pointless. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 10/02/2019 09:14, Geert Janssens wrote: Op zondag 10 februari 2019 09:56:51 CET schreef Adrien Monteleone: I’m in agreement on that note. I understand why someone who doesn’t close books would like a report that shows a current position. But the Trial Balance report is really only useful for the close books crowd. It should only reflect actual transactions in the various registers. In the case of assets then, it shouldn’t be estimating based on any user choice of average, nearest date or such, it should be taking actual purchase price just like you would if you did it on paper. In Belgium you have the choice (or at least used to have - I haven't checked lately): We can/could report the balance using purchase values or using current values, with current values meaning current at the report date. that would be for a balance sheet, p+l or similar public facing document, not a trial balance a trial balance is an internal document or work sheet to help figure out (usually) human type accounting errors like something being put on the balance sheet side rather than the p+l side or similar (e.g. an expense as a liability or some such, these are quite easy mistakes to make if you don't have formal accounting knowledge or even if you do, happen to be busy and think "I'll just post it and sort it out later") some people actually stop formal accounting training at trial balance stage in the UK, I am not joking. if you can bring a set of accounts to trial balance you will probably find work. the balance sheet and p+l are the easy parts if someone else has done the work :) if the value of a tx changed because of a share price rising or falling or an exchange rate changing it doesn't affect the trial balance at all, it is the numbers that we are seeking to balance, not their values in english language accounting we call it the trial balance because it is for testing the stuff we produce later (p+l, bs, etc) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 09/02/2019 07:00, Wm via gnucash-devel wrote: Background: My gnc TB has been wrong for years. This hasn't been a problem for me because I can do my own TB in sql and satisfy myself all is relatively well with my accounts. Over the last week or so I decided to try again and I think the gnc TB report is b0rked. OK, have a think about this. Having deleted the tx previously mentioned. If I run a TB report to 2017-12-17 it balances. If I run a TB report to 2017-12-18 it is out by .01 Problem? There are no tx on 2017-12-18 The ordinary use of a TB is to help find accounting errors. If the report introduces errors I say it is not fit to be used. https://bugs.gnucash.org/show_bug.cgi?id=797097 -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
On 09/02/2019 07:00, Wm via gnucash-devel wrote: Background: My gnc TB has been wrong for years. This hasn't been a problem for me because I can do my own TB in sql and satisfy myself all is relatively well with my accounts. Over the last week or so I decided to try again and I think the gnc TB report is b0rked. OK now it is getting weird, this tx involves no fx or trading accounts but throws the TB report out by a penny. === Exp:Week:Rec Dr 4.00 Liabilities:Accounts Payable:Y Cr 4.00 === I kid you not, the tx is for 4.00 but the TB goes wrong by .01 -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data
On 02/02/2019 18:00, John Ralls wrote: So maybe we should just forget it and continue the practice of asking users to send their account files directly to a developer with the promise of confidentiality if they're unable to reproduce the bug in a test file. That's what I'm thinking. No one has demurred yet. Not true. Some bugs just hang around longer than others. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data
On 02/02/2019 17:44, Hendrik Boom wrote: On Sat, Feb 02, 2019 at 04:30:30PM +0100, Geert Janssens wrote: Op zaterdag 2 februari 2019 14:31:43 CET schreef Hendrik Boom: On 2/1/19 5:36 AM, Wm via gnucash-devel wrote: [2] as long as the transaction stream balances the actual numbers don't matter (their will be occasions where the numbers are important but these tend to be number extremes related to commodities rather than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In most cases multiplying any matching numbers by the same semi-random should produce a good file for examination so long as it is done consistently [4] If the numbers in the file are integers times some account or currency-dependent unit, then just clculationg the greatest common divisor of all the obfuscated numbers will give a good guess as to the semirandom multiplier. Do you think that still is possible if a different random number was used for each transaction ? (That's how I understood Wm's suggestion) Each transaction will have it's own random number. So for transaction A all splits may have been multiplied with 450, for Transaction B all numbers may have been multiplied by 500. That might work. That way eash transaction balances, but the account balances will be nonsense. Still, by finding the gcd you can still produce a lower bound on the transaction values. And if you, say, split off sales tax into a separate split your lower bound will oftern be the actual value. And it's likely that one could also identify income and expense accounts as such by the pattern of debits vs credits. You're presuming a level of snooping that I don't think exists amongst Geert, John, et al. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me
Background: My gnc TB has been wrong for years. This hasn't been a problem for me because I can do my own TB in sql and satisfy myself all is relatively well with my accounts. Over the last week or so I decided to try again and I think the gnc TB report is b0rked. Looking at the bug list, I'm not making a new observation, the gnc TB is not a feature of which to be proud but I think I can help. The problems seem to be centered around two things: 1. using currency other than your home currency 2. related to that, using trading accounts Guess what? If it was that simple it would have been solved by now, right? I have loads of tx in a number of currencies using trading accounts that don't make the gnc TB throw a wobbly but have identified the first that makes it go wrong. So, let's look at a tx that does make it go wrong, maybe someone will help me to think, it is possible I've looked at this for too long and am missing something really obvious. === Liabilities:Loans:T:T ZAR Dr 7,963.46 Liabilities:Loans:T:T USD Cr 771.22 === The numbers are real, I've changed the account names slightly, I've separated this particular tx as the first that makes the gnc TB go wrong and does actually balance by my understanding of accounting and mathematics. The prices look right, the actual exchange rate is real, what is wrong? Things to consider: If the price to be used is the issue, is the gnc TB using the right price? My answer may be "yes, usually it does use the right price, I can't work out why it sometimes doesn't" Does this raise an accounting honesty issue? I think it does. If you need to roll your own to get a TB from a transaction stream something isn't right. Alternatively, please help me to see what is wrong with my tx. have a joke: Trump wants to be the Dutch boy, first he needs a dyke, then he realises his fingers are tiny :) -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 02/02/2019 15:24, Geert Janssens wrote: Yes, if you use business features, you may have entered business identifying data in File->Properties. It think that's what David is referring to. I agree, the third party should not be identified. Similarly there may be customer and vendor data (names addresses) in the book that should equally be obfuscated. Just random data is fine. Yes. Geert, at the moment I am putting guid in place of random, do you think that is a wrong way to approach this? Actually, the nearer we get to complete random the less useful the file becomes. Actual random data is harder than most people think and pretty much defeats the purpose if you think about it. Continuing on that vein, if you have bills and invoices, aside from randomizing the transaction's split amounts and values you'll also have to do the same for invoice entries. I don't think that is true in most situations and even if what you say is true, I don't see it as a good argument against *attempting* a normalized book for most people. And to make the book useful for detecting business data bugs this should happen in such a way that invoice tax and discount amounts remain consistent after multiplying with random numbers *and* that the invoice totals continue to match the business transactions amounts in AR/AP accounts. There will be situations that involve the person doing the triage needing to see actual transactions, I have already commented on that. And to make that one level more complicated, after that the payment transactions *also* have to continue to match the new randomized invoice amount (if the invoice was paid in full). U, I don't think that is true. If the munged numbers match (and they will, that is what the script will do) the transaction stream will be OK. It is possible I have missed your point, Geert, but I think it is looking like I understand the contents of the gnc files better than you :( It doesn't end there, payments can be split over multiple invoices, so again when one randomizes invoice amounts care must be taken to adjust the payments in proportion to the invoice amount change or fully paid invoices suddenly can become partially paid or overpaid. Not true. Geert, I don't want to say this but I believe you are actually wrong, for once. While this is probably all possible I believe the resulting script will be so complex that it will become a source of bugs in itself which would divert developer time to debugging and maintaining this script rather than working on the effectively reported bug for which a sample data file was asked in the first place... H, I accept your point and disagree. Up until a book with only transactions, no business data at all it sounded like a useful tool. Be a brave man, Geert, most people don't use the business functions :) Oh and we haven't mentioned SXs and budgets yet... Unless they are material to the file being investigated I suggest we just delete all SXs and budget stuff. As for Colin's question: on Windows and MacOS sqlite is supported out of the box. On linux it may require the additional installation of a libdbi driver. Most distros I know have packages for this driver but they may not be installed by default. It would be an odd distro that excluded SQLite, it is a requisite for a lot of other stuff like browsers. Thinking aloud: maybe a server only install might not have it or someone stupid enough to put their data on Amazon might not have it available. The question then becomes, why was the person so stupid? As far as I am concerned this conversation is ongoing, if only because Geert says he still needs a file from me to replicate a basic problem that I don't think needs any data from me at all. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data
On 02/02/2019 13:31, Hendrik Boom wrote: On 2/1/19 5:36 AM, Wm via gnucash-devel wrote: [2] as long as the transaction stream balances the actual numbers don't matter (their will be occasions where the numbers are important but these tend to be number extremes related to commodities rather than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In most cases multiplying any matching numbers by the same semi-random should produce a good file for examination so long as it is done consistently [4] If the numbers in the file are integers times some account or currency-dependent unit, then just clculationg the greatest common divisor of all the obfuscated numbers will give a good guess as to the semirandom multiplier. My test script includes randomness introduced by the user. Could the numbers be worked backwards? Possibly, maybe probably from a purely numeric POV. Will the remote person, having done the work, know what each of the numbers mean? Nope. That is the point I am suggesting we go for, a numerically sensible file that makes no sense to anyone else financially. Will there be times this won't work? Of course, in which case we revert to the existing system of having to trust someone with your live data. All I am offering to do is reduce the number of times someone has to trust someone. If the community decides this isn't worth the effort so be it, but I think we should at least think it through. So, Hendrik, I acknowledge your point but don't think it is significant. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 02/02/2019 16:11, Geert Janssens wrote: But I don't know how feasible it is to effectively obfuscate that data withoug resorting to a complex script The script will be seen by others that do understand sql before anyone innocent gets to use it, promise. If the script is well documented (I don't see the point of obfuscated sql when we are doing something like this as time is not the major issue, getting the problem fixed is) then people that can read will use it. Further, most of the actual gnc code is so fucking obfuscated it is acknowledged only a handful of people can read it, so do you really want to raise the issue of obfuscation, Geert? Seriously, people that don't know how code works are already trusting their financial data to code they have no clue about. Why is my suggestion going to increase or decrease trust or increase or decrease complexity? Gr. >> that may introduce its own set of bugs My script cannot introduce a bug, we are normalizing data <-- read that again, please. or inadvertently also obfuscate the actual issue. That is a possibility. I consider this a positive not a negative from a triage POV. the user says: "oops, my problem doesn't exist after I ran the normalizing script" <-- is this good or bad? if the script is well documented the user can edit it and run it again, possibly solving the problem themselves. > > The latter is quickly tested, the former is a time waster. This is a very good point and I repeat, this is not suggested as compulsory, this is intended to make things easier not harder for people that do want to report things that may be specific to them without exposing irrelevant details they may consider private or personal. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Normalizing live data, a suggestion for discussion
On 02/02/2019 15:40, David Carlson wrote: Wouldn't it be simpler to create a library of template files designed to exercise various features that a user could find one to illustrate his concern? To some extent this is already done in the build process. Life always throws up something unexpected. Further, users are by definition lazy and want the devs to look at *their* data rather than being expected to trawl through a set of files containing data not relevant to their real life situation in the hope that one of them shows the fault that, by definition, shouldn't have existed in the first place. See the circular bit? Thiswould bypass the need to figure out how to sanitize every possible user file. Sanitizing isn't that hard and we don't actually need perfection, just sufficient so that people are confident that the devs aren't snooping on them. If the user wants, he could still build his own example file as some users do now. The problem is that some people build files that don't work for everyone; it does say "normalizing" in the Subject line, none of this is ever going to be compulsory. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
