Re: [GNC] "Unrealized Losses" in Trial Balance Report
Hi all, I searched on this and found an email thread with the above title, initiated thusly: "On Mar 22, 2018, at 1:02 AM, Richard " where Richard reports the lack of balance in his Trial Balance report. The responses to his email seemed to be put it down to rounding errors and/or Check I also use Trading Accounts and I've had this problem for a few years. My workaround has been to -1- export Trial Balance report to html -2- open report in spreadsheet -3- replace report's totals with sum() functions of above rows (the sum() and report totals numbers should match) -4- do the same for the Balance Sheet report of the same date -5- Note: the gnucash Trial Balance report always has a positive number but changes the line description from Trading Gains to Trading Losses if it would otherwise be negative. In the spreadsheet, make this number negative for Trading Losses (or keep as positive for Trading Gains), and change the line description to "Trading Gains/Losses" -6- Back in the Trial Balance spreadsheet, move the "Unrealized Losses" line out of the items being summed -7- insert a new line copied from the "Trading Gains/Losses" line of the Balance Sheet -8- move the "Trading Gains/Losses" value over to the Credit column and ensure the Totals include it. -9- possibly add a line: "Rounding 0.01" to Debit or Credit column. -10- hey presto, the numbers in the Trial Balance balance! Perhaps this just works for my setup (my only "commodities" are currencies). But it would appear that wherever the "Unrealized Losses" value comes from, it is not of much use whereas the "Trading Gains/Losses" value is just the job. And perhaps I am violating some rule about not having negative numbers in Balance Sheets or Trial Balances. Anyway, I would be interested in comments from others on how they approach this problem and whether they have a workaround. Regards Phil ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Best way to Auto Sync GC Checking Transactions with the Bank?
Regarding import/update frequency, I would personally shoot for a periodicity that generates a reasonably small number of transactions at a time to handle in ten or fifteen minutes max, as that is when I start to get careless in matching. That could mean daily for some users, or about a week or two for me. To Fran_3's second point, I think the import matcher does consider descriptions and source accounts and perhaps more since the major update to the process in the release 3.x series. I believe it now works equally well for CSV imports as well as QFX/OFX or QIF imports. It may still be weak when values are similar or identical, but I don't see very much of that in my case. In any case it is essential to do the matching during the import process in order to train the matcher, as that is the only time that any training happens. On the third point, if there is any way to avoid purely graphical steps like using MS Paint that should help, if outside assistance cannot be completely eliminated. I do know that it is surprising how adept LibreOffice Calc is at converting information to spreadsheets when it is used to open PDF files, for example. That's my two cents. On Sat, Oct 17, 2020 at 7:00 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > The Help/Guide and probably the wiki (as well as various threads in this > list) will provide more insight into how the Import Matcher works, along > with tips and tricks to use it most effectively. > > My first question would be, "What is the reason for doing this daily? > What advantage over larger periods does this level of effort give you?" > > I ask, because my first recommendation would be to do so less > frequently, maybe even weekly at the most, but monthly would be a most > likely target. What you appear to be doing is essentially reconciliation > and that is traditionally (though it doesn't have to be) a monthly > procedure. > > I don't download bank transactions or use the import matcher myself, but > after reading many, many threads here on the various nuances, I'd think > the matcher *should* recognize 'amount', 'date', and 'description' and > flag those qualifying transactions as potential duplicates. You get to > decide before completing the import if they really are duplicates. If > you leave them marked as such, if I recall correctly, GnuCash will > change the flag in the "r" column from 'n' to 'c'—meaning the > transaction has cleared the bank. When you do a formal reconciliation of > the account with a periodic bank statement, those marked 'c' will be > pre-checked for you. You would only need to verify and check off the > remaining transactions in the reconcile window. > > The date that your bank shows for the transaction may not be the same > date as the real-world transaction. (the real date *should* be what you > have entered in GnuCash) I think the matcher is smart enough to flag > those for a closer look if the other key data matches. > > For transactions that don't qualify as true duplicates (thus needing to > just be 'cleared') they will be imported as new with the 'c' flag > already set. > > My second question is, "Why are you doing the comparison manually > outside of GnuCash when GnuCash has built-in methods of helping you find > those duplicates?" > > If you still really need to do a comparison outside the matcher, yes, > there are ways to script it, to a point. But I caution that approach > because it will be a bit of work to set up and my suspicion is you'll > find most of that effort will be duplicating what GnuCash is already > capable of. > > Regards, > Adrien > > On 10/16/20 9:45 AM, Fran_3 via gnucash-user wrote: > > Given a checking account with a number incidental and auto pay > transactions ocuring daily... > > Is there a way to automate...- logging on to the bank daily- determining > which transactions have hit the bank but are not posted in GnuCash- then > updating GnuCash with those unrecorded transactions? > > Doing this manually when the account has a number of incidential and > auto pay transactions occurring daily is a lot of work.It is also prone for > error as the transaction date and description at the bank do not always > match how they are entered in GnuCash. > > Manually we have been daily downloading CSV files, and comparing them in > spreadsheets...or screen capturing the latest bank transactions and the > latest GC transactions, pasting them into PC Paint, and then doing the > compare.or printing them out on paper to do the compare. > > In summary...1 - How can we automate this daily task?2 - If there is a > way... does GC use the description field and amount field to "match" > transactions?3 - or what? > > Thanks for any help. > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please
Re: [GNC] The type of trading accounts
They show up in their own section if I'm not mistaken. While the original question is interesting, I wonder how practical the answer is. Regards, Adrien On 10/17/20 11:58 AM, Stan Brown wrote: And of asset accounts. One way to determine whether its expense account or an asset account is to run a balance sheet and see if it shows up there. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Exchange rate of income statement report
Gal, Have you investigated using the Trading Accounts feature? While I do have some multi-currency transactions in my book, I rarely need to do so, but turning on Trading Accounts helped me make sense of them. A caveat, as I believe Will noted: I enter exact amounts for each currency because those are known at the time. But I could also enter one currency and let GnuCash grab that day's exchange rate and enter the other currency for me. When you use Trading Accounts, foreign currency transactions (accounts not in your 'book' currency) will have 2 splits for each debit and credit that are designed to balance your book taking both currencies into account. (so you will have a debit in USD, a debit in ISL, a credit in USD and a credit in ISL) This will essentially 'fix' those transactions to the exchange rate on that day. (or whatever rate you used, so you'll have to make a point to have it grab the rate if needed in the dialog box that will pop up when entering the transaction) Your reports should then make more sense and be complete. As for the income question, now you're dabbling into the realm of tax-implicated questions. Those should be answered by the relevant certified professionals. (in each jurisdiction) For your own informational purposes, I don't see why those transactions couldn't be entered the same way. Concerning the report option for choosing a price source, I vaguely recall either a mailing list or Bugzilla discussion concerning the complexities and that some of the options were not working properly anyway, so rather than have a buggy report, it was decided to hard-code a known working option (in this case price source) for now. Regards, Adrien On 10/16/20 4:01 PM, Gal wrote: Michael or Penny Novack wrote Accounting is all about information. Maybe if you explained what information was being kept for it would make more sense retaining both in one set of books. Note that if there were some restrictions on conversion, accounts in separate countries subject to such restriction, I would probably suggest separate books. The information is being kept for personal finance tracking. I want to be able for example to compare an expense type between different years. I understand your point about needing to keep track of the original currency only if you consider evaluation at other dates, but I still see no drawback in doing so even if I only, currently at least, care about translation at transaction date. I do get the benefit of more convenient transaction entering + keeping data at its purest original form. With expenses it may not be so visible but what about incomes? If my employer pays part of my compensation in forex, should I translate that too? if not, why distinguish between incomes and expenses? Regarding the translation by transaction date: the transaction report mentioned by Christopher Lam was kinda helpful to achieve what I was looking for. It seems to implicitly choose "nearest in time" price source, as I couldn't find a way to change the price source in its options menu. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Best way to Auto Sync GC Checking Transactions with the Bank?
The Help/Guide and probably the wiki (as well as various threads in this list) will provide more insight into how the Import Matcher works, along with tips and tricks to use it most effectively. My first question would be, "What is the reason for doing this daily? What advantage over larger periods does this level of effort give you?" I ask, because my first recommendation would be to do so less frequently, maybe even weekly at the most, but monthly would be a most likely target. What you appear to be doing is essentially reconciliation and that is traditionally (though it doesn't have to be) a monthly procedure. I don't download bank transactions or use the import matcher myself, but after reading many, many threads here on the various nuances, I'd think the matcher *should* recognize 'amount', 'date', and 'description' and flag those qualifying transactions as potential duplicates. You get to decide before completing the import if they really are duplicates. If you leave them marked as such, if I recall correctly, GnuCash will change the flag in the "r" column from 'n' to 'c'—meaning the transaction has cleared the bank. When you do a formal reconciliation of the account with a periodic bank statement, those marked 'c' will be pre-checked for you. You would only need to verify and check off the remaining transactions in the reconcile window. The date that your bank shows for the transaction may not be the same date as the real-world transaction. (the real date *should* be what you have entered in GnuCash) I think the matcher is smart enough to flag those for a closer look if the other key data matches. For transactions that don't qualify as true duplicates (thus needing to just be 'cleared') they will be imported as new with the 'c' flag already set. My second question is, "Why are you doing the comparison manually outside of GnuCash when GnuCash has built-in methods of helping you find those duplicates?" If you still really need to do a comparison outside the matcher, yes, there are ways to script it, to a point. But I caution that approach because it will be a bit of work to set up and my suspicion is you'll find most of that effort will be duplicating what GnuCash is already capable of. Regards, Adrien On 10/16/20 9:45 AM, Fran_3 via gnucash-user wrote: Given a checking account with a number incidental and auto pay transactions ocuring daily... Is there a way to automate...- logging on to the bank daily- determining which transactions have hit the bank but are not posted in GnuCash- then updating GnuCash with those unrecorded transactions? Doing this manually when the account has a number of incidential and auto pay transactions occurring daily is a lot of work.It is also prone for error as the transaction date and description at the bank do not always match how they are entered in GnuCash. Manually we have been daily downloading CSV files, and comparing them in spreadsheets...or screen capturing the latest bank transactions and the latest GC transactions, pasting them into PC Paint, and then doing the compare.or printing them out on paper to do the compare. In summary...1 - How can we automate this daily task?2 - If there is a way... does GC use the description field and amount field to "match" transactions?3 - or what? Thanks for any help. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] v4.2 report numbers change over gnucash restarts; Price Database dropping user:price-editor entries.
I filed the issue/enhancement request as https://bugs.gnucash.org/show_bug.cgi?id=797983 On 18/10/20 10:15 am, John Ralls wrote: > > >> On Oct 16, 2020, at 10:15 PM, Phil Diacono wrote: >> > > I'm able to reproduce the problem with losing prices, but only with the SQL > backend. It works as expected for me on the XML backend. > > Regards, > John Ralls > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] v4.2 report numbers change over gnucash restarts; Price Database dropping user:price-editor entries.
> On Oct 16, 2020, at 10:15 PM, Phil Diacono wrote: > > Hi team, > > I have a vague recollection something like this happened a few years ago > but it was just a display issue, restarting gnucash would display the > seemingly missing manually added currency conversion rate. > > However with v4.2, I'm actually seeing the added conversion rate for the > end-of-financial-quarter date being lost after a restart of gnucash. > What's more conversions in reports with settings "nearest" are now > pulling in an entry from a different date (since the eofq date has > disappeared), so the reports' numbers have changed between gnucash sessions! > > Eek! > > Procedure: > > Example report: Balance Sheet, options -> commodities -> Price Sourcec: > Nearest in time and tick "Show Foreign Currencies" and "Show Exchange > Rates". > > Line item for Paypal-USD reads: > US$898.50 A$1,1239.99 (= exchange rate of 1.380067, presumably taken > from an existing 10 Oct 2020 Price Database entry 1.380063) > > Define exchange rate for end-of-financial-quarter: > Tools -> Price Database -> Currencies -> USD (US Dollar) -> Add -> > Namespace: Currencies > Security: USD (US Dollar) > Currency: AUD (Australian Dollar) > Date: 30/09/20 > Type: Last > Price: 1.39638 > OK > > Reload Balance Sheet Report: > > Line item for Paypal-USD now reads: > US$898.50 A$1,254.65 (= exchange rate of 1.396383 matching the 30 > Sep 2020 entry we manually put into Price Database) > > So far so good. > > Exit gnucash. Re-enter gnucash. > > Line item for Paypal-USD now reverted to: > US$898.50 A$1,1239.99 > > Price Database entry for 30 Sep 2020 now missing (even after sorting on > date column)! Report number changed over gnucash restart! > > Anyone else seeing this? > > Config details: > Running Ubuntu 20.04.1 LTS on x64. > Gnucash Version: 4.2 > Build ID: 4.2+(2020-09-26) > Finance::Quote: - > It was built using cmake and uses a SQLite 3.x database backend: > libdbd-sqlite3:amd640.9.0-8ubuntu1 > libsqlite3-0:amd64 3.31.1-4ubuntu0.2 > libsqlite3-dev:amd643.31.1-4ubuntu0.2 > I'm able to reproduce the problem with losing prices, but only with the SQL backend. It works as expected for me on the XML backend. Regards, John Ralls ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] The type of trading accounts
On 2020-10-17 04:42, Gal wrote: > But on the other hand, when I open a trading account register, I see that > money coming into the account (debit) is increasing its balance, and money > going out of the account (credit) is decreasing the balance, but this is the > behavior of expense accounts. And of asset accounts. One way to determine whether its expense account or an asset account is to run a balance sheet and see if it shows up there. -- Stan Brown Tehachapi, CA, USA https://BrownMath.com https://OakRoadSystems.com > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] transaction report missing subtotals
I see the problem. After some experimentation I failed to discover a solution. Hopefully someone else here can chip in. On Saturday, October 17, 2020, 3:57:15 AM EDT, Gal wrote: GnuCash - User mailing list wrote > .. On Sorting Tab - set Primary Key to Date to "enable " Primary Subtotal > Date Key) When the primary key is the date, the primary subtotal are displayed. The issue arises when the date is chosen as the secondary key, in which case "secondary subtotal" checkbox can't be checked, and accordingly, no monthly subtotals are displayed in the table. Why are date subtotals limited to appear only when the date is the primary key? -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] The type of trading accounts
Does a trading account, i.e. an account of type "Trading" that was auto created by the system, acts like an income account or like an expense account? On one hand the concept behind this account type classifies it as an income account: https://www.mscs.dal.ca/~selinger/accounting/tutorial.html "By convention, gains are recorded positively and losses negatively, and therefore a currency trading account is a kind of income account." The tutorial also classifies it as an income account by its placement and sign in the accounting equation: https://www.gnucash.org/docs/v4/C/gnucash-guide/currency_trading_accts.html Assets = Liabilities + Equity (+ Income -Expenses) + Trading But on the other hand, when I open a trading account register, I see that money coming into the account (debit) is increasing its balance, and money going out of the account (credit) is decreasing the balance, but this is the behavior of expense accounts. -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] transaction report missing subtotals
GnuCash - User mailing list wrote > .. On Sorting Tab - set Primary Key to Date to "enable " Primary Subtotal > Date Key) When the primary key is the date, the primary subtotal are displayed. The issue arises when the date is chosen as the secondary key, in which case "secondary subtotal" checkbox can't be checked, and accordingly, no monthly subtotals are displayed in the table. Why are date subtotals limited to appear only when the date is the primary key? -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
