Re: [GNC] Exchange Rate to Price Database issue with low transactions amounts
Bo: Thank you for a good question! John Ralls already gave you an answer, and it is correct. John writes the code, he knows whereof he speaks. But let me try to explain it a different way. On 2025-02-09 04:36, Bo Buckley wrote: ...I recently tried to add a JPY checking account to my books I noticed all smaller transactions (e.g. wire fees, interest, etc.) were all being converted incorrectly ...you will see the following: Date Description Transaction Amount ExchangeRateGivenInTransferFundsDialog ExchangeRateRecordedInPriceDatabase 2025/01/29 Transfer Fee 110 0.0066 0.00909090909090909 2025/01/29 Transfer Fee 150 0.0066 0.00667 2025/01/29 Transfer Fee 200 0.0066 0.005 2025/01/29 Transfer Fee 300 0.0066 0.00667 2025/01/29 Transfer Fee 500 0.0066 0.006 2025/01/29 Transfer Fee 1000 0.0066 0.007 2025/01/29 Transfer Fee 2000 0.0066 0.0065 2025/01/29 Transfer Fee 5000 0.0066 0.0066 2025/01/29 Transfer Fee 1 0.0066 0.0066 Thank you for clearly explaining what you did and what you saw. That is helpful. (I have not tried to reproduce it, I believe your evidence.) My expectation is that whatever is entered into the "Exchange Rate" will be used and saved into the Price Database. This is not happening This is an incorrect expectation. GnuCash does not behave this way. Exchange rates used in transactions might get saved to the Price Database, but as John said, there is only one entry per calendar day. Different rates on the same day will overwrite preceding rates. Exchange rates from the Price database might get used as the default value in the Transfer Funds dialogue, but what you enter there will take precedence. For the smaller transaction amount (in this example case < 5000 JPY) the Exchange Rate Recorded in Price Database appears to change on its own accord and not even linearly. What really stinks is that this all happens silently... My only guess is this has to be something to do with a rounding error Not quite rounding error. The conceptual mistake is to treat the exchange rate as fundamental. It is not. It is merely the ratio of value in currency A to value in currency B. AFAIK GnuCash does not even store that ratio. It is the values in the two currencies which are fundamental. In your example, when importing each transaction and filling out the Transfer Funds dialogue, I think you will have better results if you disregard the Exchange Rate field, and concentrate on entering the correct USD amount for the Expenses:Bank Service Charge account. When the Transfer Fee was 1, JPY, what was the USD amount of the service charge? If it was 64.42 USD, then enter that. The exchange rate field will show a rational number, maybe something like 3221/5. That is approximately 0.00644, but exactly 64.42/1,. When the Transfer Fee was 300 JPY, what was the USD amount of that service charge? If it was 1.93 USD, and you enter that, the rational number in the Exchange Rate field might be something like 193/3. That is approximately 0.00643, but exactly 300/1.93. And so on for a fee of 110 JPY, which might be a service charge of 0.71 USD, with an exchange rate of 71/11000, approximately 0.00645. ... So two summarizing questions: 1. Is this a known bug on bugzilla? I could not find it via a Google mailinglist search or on bugzilla The best answer is, the Exchange Rate computation is a feature, not a bug. However, we can also see from your observations that the Transfer Funds dialogue and how it applies to multi-currency transactions is confusing. Also, the documentation is inadequate. I totally agree about that. I enter such transactions all the time, and I still get confused by GnuCash's mechanisms. 2. Is there a known workaround? Yes. When entering data into the Transfer Funds dialogue, do not enter numbers into the Exchange Rate field. Use it solely to check your work. Concentrate on entering the correct transaction value amounts in each currency in their two fields. Does that help? —Jim DeLaHunt ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Searching mailing lists
On Sun, 9 Feb 2025 20:21:59 +0900 Bo Buckley wrote: > > According to the mailing list docs: > > > Currently, there is no on-site mechanism to search the mailing lists > > *and the search link on the archive page is broken.*Instead, use > > the term "site:lists.gnucash.org" at Google or Yahoo! to search > > within the archives, e.g. > > http://www.google.com/search?q=site%3Alists.gnucash.org+string+to+search > > > Using the technique actually referenced here https://lists.gnucash.org/search/?idxinfo=gnucash-user, and duckduckgo led me to this (I used csv as the string to search) https://www.mail-archive.com/gnucash-user@gnucash.org/msg44075.html Liz ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 to Price Database issue with low transactions amounts
> On Feb 9, 2025, at 17:32, Bo Buckley wrote: > @John Ralls, would you be able to point to where in the codebase this is > handled (i.e. where the Exchange Rate from the Transfer Funds Dialog is > taken and how the Price Database entry Price is calculated?) I'd understand > a lot better seeing the code. Otherwise I'm lost on why this has to be left > as a known rounding error and cannot be handled some other way. > There is no one place. The price database is implemented in libgnucash/engine/commodity.cpp. The transfer dialog, of which the exchange rate section is a part, is in gnucash/gnome-utils/dialog-transfer.c. Transaction balancing is in libgnucash/engine, with pieces of it in Transaction.cpp, Split.cpp, and Scrub.cpp. IIRC transaction currency selection happens somewhere in gnucash/register/ledger-core/ but I don’t know offhand which file. For the rest, you need to understand that the price database entry is a record of the last price retrieved or calculated on a particular day. (That’s not quite true, but let’s not digress into why not, it’s not important for the discussion at hand. Each split has an amount of and a value. I explained what those are in my previous letter. They don’t have an explicit price. Perhaps an example will help. You postulated an exchange rate of $0.66/100¥. Suppose you have two splits, one for 175¥ and one for 270¥. The first one is $1.155, but there’s no such thing as half-pennies in US currency so it gets rounded to $1.16. The second is 1.782 and is rounded to $1.78. The *stored numbers* for the first split are 175¥ (amount) and $1.16 (value), *implying* a price of 116/17500 or ~.006685714285714… $/¥, The second split stores an amount of 270 and a value of 1.78, *implying* a price of 178/27000 or ~.006592595…. (GnuCash uses the exact rational number internally; decimals are used only for display.) I said “implying” because while one of those prices might get stored in the price database it’s quite possible that neither will or that the price in the price database will get overwritten later. GnuCash must work this way in order for transactions, accounts, and the book to balance and stay balanced. The price database is there to calculate values for reports and the Accounts page, but reports have an option to calculate a average cost from individual splits, and that option is the only one that will allow the Trial Balance report to balance. 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] confusion on new fields in csv import
David I think the main issue is there is no well defined protocol/standard for CSV data and the importer does not know where the CSV file originates and whether the data is presented from the perspective of the entity which provided the data or that of the entity which has received the data which makes the use of the terms Debit/Credit and or Deposit/Withdrawal ambiguous. If these terms were used in the internal headers assigned to the columns of data there would be circumstances in which the header Debit had to be applied to a column which the source of the file labelled as Credit a common occurrence with data from Banks for example. I think the idea is to provide for maximum flexibility in the use of the CSV data which means that the user importing the data has to be cognizant of the origins of the data and the entity for which it was prepared and the relationship to the entity whose books the data is being imported into. David Cousens On Sun, 2025-02-09 at 10:15 +0300, sunfish62--- via gnucash-user wrote: > Since no one else has stepped in, I'll add my perspective. Please > bear in mind that I don't use csv imports much. > > You originally asked what relationship the new terms had to the old > ones. > > My recollection of the discussions (which take place on gnucash.org, > not reddit or github, fysa) is that the earlier terminology > (Deposit/Withdrawal) was ambiguous and would vary depending on the > account type. Formal accountants in the user group felt that these > terms should be replaced with more accurate ones. > > I don't recall now why the formal accounting terms (Debit/Credit) > weren't chosen-- but I do know that the option was considered and > dropped consciously. > > The ultimate decision as I recall was to use the Amount/ Amount > (Negated) terminology as a compromise. I don't recall anything about > single versus double column csv formats. > > To answer your original question, Amount and Amount (Negated) > correspond to Deposit and Withdrawal. I suspect Transfer Amount and > Transfer Amount (Negated) are used in different account types and > also correspond to Deposit and Withdrawal. > > Which new entry goes with which old entry I can't say because I don't > use csv imports and I am not an accountant. I imagine a few trials > would quickly answer the question, though. > > David T. > > On Feb 9, 2025, 8:30 AM, at 8:30 AM, Gio Bacareza > wrote: > > So I searched more in Reddit and GitHub and it seems that this has > > not > > been > > resolved yet. Here's the summary of my findings if any of you would > > find it > > useful. > > > > - *May 2023 – rellieberman*: Reported confusion over removal of > > *Deposit/Withdrawal* fields in CSV import. > > - *May 2023 – Vincent Dawans, John Ralls*: Discussed renaming > > *"Amount > > (Negated)"* to *"Amount (sign-reversed)"* and adding *dynamic > > labels > > per > > account type*. > > - *May–June 2023 – Community Discussion*: Debated *single-column > > vs. > > dual-column support* and whether to use *formal Debit/Credit > > labels*. > > - *July 1, 2023 – **dawansv*: moved convo to Bug 798922 - No > > withdrawal/deposit fields in csv import dialog #1699 and Proposed > > dynamic > > column labels based on *base account selection* and UI > > improvements* > > commit*: > > Implemented *dynamic column labels*, added *formal accounting > > labels*, > > and > > updated *import instructions*. > > - *July 2023 – nomis, flywire, gjanssens*: Suggested keeping > > *dual-column > > support* but ensuring *single-column imports work*. > > - *February 2025 – User Testing (you)*: Found that *single-column > > "Amount" > > import does not work*, requiring *dual-column workaround*. > > - *Current Status*: Feature *not fully functional*; likely > > *incomplete > > implementation or a bug*. Bug report recommended. > > > > sources https://bugs.gnucash.org/show_bug.cgi?id=798922 and > > https://github.com/Gnucash/gnucash/pull/1699 > > > > On Sun, Feb 9, 2025 at 12:38 PM Gio Bacareza > > wrote: > > > > > Dear Brad and Others, > > > > > > Thank you for your response. > > > > > > I appreciate the link you provided, but it seems to only discuss > > > QIF > > > conversions. While I may consider QIF in the future, I'm > > > currently > > looking > > > for guidance specifically on the new CSV import fields in GnuCash > > 5.10. > > > > > > I've used CSV import successfully in the past. However, the > > > recent > > update > > > introduced new terminology (Amount, Amount (Negated), Transfer > > Amount, > > > Transfer Amount (Negated)) that I'm struggling to understand in > > relation to > > > my previous CSV structure. > > > > > > I have already searched the GnuCash documentation and wikis, but > > > I > > haven't > > > found any information about these new terms. The documentation > > > still > > seems > > > to refer to the old "Withdrawal" and "Deposit" fields. > > > > > > For example from > > > https://www.gnucash.org/viewdoc.phtml?rev=5&lang=
Re: [GNC] Searching mailing lists
I am not sure what the official position is re the mail archive site. AFAIK it mirrors posts to the official lists which are maintained by the GnuCash team and moderated by Liz. I just find it much easier to locate posts and threads on the mail archive site that in the official mailing lists. david Cousens On Mon, 2025-02-10 at 11:34 +0900, Bo Buckley wrote: > Thank you for the links David. That is helpful. Is this link not > listed in the docs anywhere? If not, are you not seeing a bunch of > duplicate questions in the mailing lists? Seems like having a clearly > explained method for searching for duplicates would be of somewhat > high priority to keep the lists from being overwhelming. > > I didn't see any response from Liz though. Still confused on how this > email list is supposed to work if I'm not seeing all replies to my > question. > > Thanks again > > On Mon, Feb 10, 2025 at 11:21 AM David Cousens > wrote: > > > > As well as the method Liz mentioned it is also possible to access > > and > > search the mailing list archives at > > > > https://www.mail-archive.com/gnucash-user@gnucash.org/ > > > > https://www.mail-archive.com/gnucash-devel@gnucash.org/ > > > > You need to have existing membership of the mailing list. I cannot > > remember whether or not this site will request membership if you > > are > > not already a list member. > > > > David Cousens > > > > > > On Sun, 2025-02-09 at 20:21 +0900, Bo Buckley wrote: > > > In the docs: > > > https://wiki.gnucash.org/wiki/GnuCash_Forum > > > > > > If claims: > > > > > > > The *GnuCash project* does *not* use ancient *forum* software > > for > > > > its > > > > online user support. It uses mailing list technology. > > > > > > > > > I'm completely lost as to the advantage of using a mailing list > > over > > > an > > > indexed searchable forum, Github Discussions, or otherwise. In > > > particular > > > I'm really struggling to find a way to find if my existing issue > > has > > > already been discussed somewhere as the only thing indexed > > appears to > > > be > > > bugzilla and the FAQs. > > > > > > According to the mailing list docs: > > > > > > > Currently, there is no on-site mechanism to search the mailing > > > > lists > > > > *and the search link on the archive page is broken.*Instead, > > use > > > > the term > > > > "site:lists.gnucash.org" at Google or Yahoo! to search within > > the > > > > archives, e.g. > > > > > > http://www.google.com/search?q=site%3Alists.gnucash.org+string+to+search > > > > > > > > > > I'm not sure if this worked well at one point, but it definitely > > does > > > not > > > work well for me now. See attached screenshot. It appears > > Google's > > > crawler > > > somehow finds its way to all the docs and other general content > > via > > > the > > > lists.gnucash.org, so it is not filtering out hardly anything as > > I > > > would > > > expect. The only alternative approach I can find is to browse > > (not > > > search) > > > https://lists.gnucash.org/pipermail/gnucash-user/, which I think > > > everyone > > > can appreciate to not be an exactly speedy process. > > > > > > Is there a better way to verify existing discussions/issues > > > (including this > > > one)? > > > ___ > > > gnucash-user mailing list > > > gnucash-user@gnucash.org > > > To update your subscription preferences or to unsubscribe: > > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > > - > > > 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 - 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 to Price Database issue with low transactions amounts
Thank you for another reply John. What you explain makes sense to me, but it is not the observed behavior from my version of GNUCash. If it were the same, I would not have an issue. Let me use your same example values. You postulated an exchange rate of $0.66/100¥. Suppose you have two splits, > one for 175¥ and one for 270¥. The first one is $1.155, but there’s no > such thing as half-pennies in US currency so it gets rounded to $1.16. The > second is 1.782 and is rounded to $1.78. The *stored numbers* for the first > split are 175¥ (amount) and $1.16 (value), *implying* a price of 116/17500 > or ~.006685714285714… $/¥, The second split stores an amount of 270 and a > value of 1.78, *implying* a price of 178/27000 or ~.006592595 Take the following values (Note I leave in two extra examples of 110 JPY and 20 JPY as the exhibit extreme examples: Date Description Transaction Amount 2025/01/29 Transfer Fee 20 2025/01/29 Transfer Fee 110 2025/01/29 Transfer Fee 175 2025/01/29 Transfer Fee 270 Within the Transfer Funds Dialog for each, I manually set the Exchange Rate to 0.0066. As you explained, I would expect that I get The second split stores an amount of 270 and a value of 1.78, *implying* a > price of 178/27000 But what I actually get is a price of 1/135, which if brought to a common denominator would be 200/27000, not 178/27000. Thats over by 200/178 or ~12% Moving forward to the 175 JPY case, I again enter 0.0066 as the exchange rate in the Transfer Funds dialog expecting whatever I specify to be used instead of any existing entry in the Price Database. Now I would expect based on your explanation: The *stored numbers* for the first split are 175¥ (amount) and $1.16 > (value), *implying* a price of 116/17500 But instead, I see the Price Database entry is now updated to have a value of 1/175, which bringing to the common denominator would be 100/17500 not 116/17500. Thats under by 110/116 or ~ 5%. This alone should be alerting, but moving forward to the more extreme examples brings further alarm. For the 110 case, I again enter 0.0066 manually for the Exchange Rate, and would expect based on your explanation that 110 JPY * 0.0066 would give 0.726 USD then rounded off to 0.73 USD. Or a price of 73/11000, but in face the Price Database records 1/110 as the Price. Matching denominators that would be an expected price of 73/11000 vs an actual price of 100/11000. Thats over by 100/73 or ~ 37%. Even more extreme, for the 20 JPY case, entering in 0.0066 for the Exchange Rate, I would expect from your explanation to see 20*0.0066 = 0.132 USD rounded to 0.13 USD, with a price of 13/2000, but instead the Price Database records 0. Not an ratio of 64 bit ints. Not a decimal representation, but flat out 0. The Match Transaction Dialog, even after pressing OK in the Transfer Funds Dialog, will still give an error "UNBALANCE (need price to transfer JPY-20 to acct Expenses:Bank Service Charge)!" ... i.e. the same error as prior to setting the exchange rate. If I then press apply and close, and view the JapaneseChecking account (see attached), You will see all the results I described above. I'm also attaching the test.gnucash file that was used to generate these numbers. Looking forward to your reply and thanks again. On Mon, Feb 10, 2025 at 1:25 PM John Ralls wrote: > > > On Feb 9, 2025, at 17:32, Bo Buckley wrote: > > @John Ralls, would you be able to point to where in the codebase this is > > handled (i.e. where the Exchange Rate from the Transfer Funds Dialog is > > taken and how the Price Database entry Price is calculated?) I'd > understand > > a lot better seeing the code. Otherwise I'm lost on why this has to be > left > > as a known rounding error and cannot be handled some other way. > > > There is no one place. The price database is implemented in > libgnucash/engine/commodity.cpp. The transfer dialog, of which the exchange > rate section is a part, is in gnucash/gnome-utils/dialog-transfer.c. > Transaction balancing is in libgnucash/engine, with pieces of it in > Transaction.cpp, Split.cpp, and Scrub.cpp. IIRC transaction currency > selection happens somewhere in gnucash/register/ledger-core/ but I don’t > know offhand which file. > > For the rest, you need to understand that the price database entry is a > record of the last price retrieved or calculated on a particular day. > (That’s not quite true, but let’s not digress into why not, it’s not > important for the discussion at hand. > > Each split has an amount of and a value. I explained what those are in my > previous letter. They don’t have an explicit price. > > Perhaps an example will help. You postulated an exchange rate of > $0.66/100¥. Suppose you have two splits, one for 175¥ and one for 270¥. > The first one is $1.155, but there’s no such thing as half-pennies in US > currency so it gets rounded to $1.16. The second is 1.782 and is rounded to > $1.78. The *stored numbers* for the first split are 175¥ (amount) and $1.16 > (v
Re: [GNC] Exchange Rate to Price Database issue with low transactions amounts
I hesitate to jump in here, since you've already got the best advisor in John, but... You keep entering the exchange rate, and it's been stated clearly before that the exchange rate is not stored and is not reliable. You mentioned in passing previously that you don't know the destination amount, and also that the JPY fees are entered into a JPY account, which explains your not knowing how much that turns into in USD. I think the proper solution here would be to create a separate transaction fees expense account denominated in JPY, thus obviating the need to rely on an inaccurate exchange rate altogether. I believe that GnuCash can provide USD amounts for these JPY expenses in the reporting system. David T. On Feb 10, 2025, 8:18 AM, at 8:18 AM, Bo Buckley wrote: >Thank you for another reply John. > >What you explain makes sense to me, but it is not the observed behavior >from my version of GNUCash. If it were the same, I would not have an >issue. > >Let me use your same example values. > >You postulated an exchange rate of $0.66/100¥. Suppose you have two >splits, >> one for 175¥ and one for 270¥. The first one is $1.155, but there’s >no >> such thing as half-pennies in US currency so it gets rounded to >$1.16. The >> second is 1.782 and is rounded to $1.78. The *stored numbers* for the >first >> split are 175¥ (amount) and $1.16 (value), *implying* a price of >116/17500 >> or ~.006685714285714… $/¥, The second split stores an amount of 270 >and a >> value of 1.78, *implying* a price of 178/27000 or ~.006592595 > > >Take the following values (Note I leave in two extra examples of 110 >JPY >and 20 JPY as the exhibit extreme examples: >Date Description Transaction Amount >2025/01/29 Transfer Fee 20 >2025/01/29 Transfer Fee 110 >2025/01/29 Transfer Fee 175 >2025/01/29 Transfer Fee 270 > >Within the Transfer Funds Dialog for each, I manually set the Exchange >Rate >to 0.0066. As you explained, I would expect that I get > >The second split stores an amount of 270 and a value of 1.78, >*implying* a >> price of 178/27000 > > >But what I actually get is a price of 1/135, which if brought to a >common >denominator would be 200/27000, not 178/27000. Thats over by 200/178 or >~12% > >Moving forward to the 175 JPY case, I again enter 0.0066 as the >exchange >rate in the Transfer Funds dialog expecting whatever I specify to be >used >instead of any existing entry in the Price Database. Now I would expect >based on your explanation: > >The *stored numbers* for the first split are 175¥ (amount) and $1.16 >> (value), *implying* a price of 116/17500 > > >But instead, I see the Price Database entry is now updated to have a >value >of 1/175, which bringing to the common denominator would be 100/17500 >not >116/17500. Thats under by 110/116 or ~ 5%. > >This alone should be alerting, but moving forward to the more extreme >examples brings further alarm. > >For the 110 case, I again enter 0.0066 manually for the Exchange Rate, >and >would expect based on your explanation that 110 JPY * 0.0066 would give >0.726 USD then rounded off to 0.73 USD. Or a price of 73/11000, but in >face >the Price Database records 1/110 as the Price. Matching denominators >that >would be an expected price of 73/11000 vs an actual price of 100/11000. >Thats over by 100/73 or ~ 37%. > >Even more extreme, for the 20 JPY case, entering in 0.0066 for the >Exchange >Rate, I would expect from your explanation to see 20*0.0066 = 0.132 USD >rounded to 0.13 USD, with a price of 13/2000, but instead the Price >Database records 0. Not an ratio of 64 bit ints. Not a decimal >representation, but flat out 0. The Match Transaction Dialog, even >after >pressing OK in the Transfer Funds Dialog, will still give an error >"UNBALANCE (need price to transfer JPY-20 to acct Expenses:Bank Service >Charge)!" ... i.e. the same error as prior to setting the exchange >rate. > >If I then press apply and close, and view the JapaneseChecking account >(see >attached), You will see all the results I described above. I'm also >attaching the test.gnucash file that was used to generate these >numbers. > >Looking forward to your reply and thanks again. > >On Mon, Feb 10, 2025 at 1:25 PM John Ralls wrote: > >> >> > On Feb 9, 2025, at 17:32, Bo Buckley >wrote: >> > @John Ralls, would you be able to point to where in the codebase >this is >> > handled (i.e. where the Exchange Rate from the Transfer Funds >Dialog is >> > taken and how the Price Database entry Price is calculated?) I'd >> understand >> > a lot better seeing the code. Otherwise I'm lost on why this has to >be >> left >> > as a known rounding error and cannot be handled some other way. >> > >> There is no one place. The price database is implemented in >> libgnucash/engine/commodity.cpp. The transfer dialog, of which the >exchange >> rate section is a part, is in gnucash/gnome-utils/dialog-transfer.c. >> Transaction balancing is in libgnucash/engine, with pieces of it in >> Transaction.cpp, Split.cpp, and
Re: [GNC] Searching mailing lists
As well as the method Liz mentioned it is also possible to access and search the mailing list archives at https://www.mail-archive.com/gnucash-user@gnucash.org/ https://www.mail-archive.com/gnucash-devel@gnucash.org/ You need to have existing membership of the mailing list. I cannot remember whether or not this site will request membership if you are not already a list member. David Cousens On Sun, 2025-02-09 at 20:21 +0900, Bo Buckley wrote: > In the docs: > https://wiki.gnucash.org/wiki/GnuCash_Forum > > If claims: > > > The *GnuCash project* does *not* use ancient *forum* software for > > its > > online user support. It uses mailing list technology. > > > I'm completely lost as to the advantage of using a mailing list over > an > indexed searchable forum, Github Discussions, or otherwise. In > particular > I'm really struggling to find a way to find if my existing issue has > already been discussed somewhere as the only thing indexed appears to > be > bugzilla and the FAQs. > > According to the mailing list docs: > > > Currently, there is no on-site mechanism to search the mailing > > lists > > *and the search link on the archive page is broken.*Instead, use > > the term > > "site:lists.gnucash.org" at Google or Yahoo! to search within the > > archives, e.g. > > http://www.google.com/search?q=site%3Alists.gnucash.org+string+to+search > > > > I'm not sure if this worked well at one point, but it definitely does > not > work well for me now. See attached screenshot. It appears Google's > crawler > somehow finds its way to all the docs and other general content via > the > lists.gnucash.org, so it is not filtering out hardly anything as I > would > expect. The only alternative approach I can find is to browse (not > search) > https://lists.gnucash.org/pipermail/gnucash-user/, which I think > everyone > can appreciate to not be an exactly speedy process. > > Is there a better way to verify existing discussions/issues > (including this > one)? > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Searching mailing lists
Thank you for the links David. That is helpful. Is this link not listed in the docs anywhere? If not, are you not seeing a bunch of duplicate questions in the mailing lists? Seems like having a clearly explained method for searching for duplicates would be of somewhat high priority to keep the lists from being overwhelming. I didn't see any response from Liz though. Still confused on how this email list is supposed to work if I'm not seeing all replies to my question. Thanks again On Mon, Feb 10, 2025 at 11:21 AM David Cousens wrote: > > As well as the method Liz mentioned it is also possible to access and > search the mailing list archives at > > https://www.mail-archive.com/gnucash-user@gnucash.org/ > > https://www.mail-archive.com/gnucash-devel@gnucash.org/ > > You need to have existing membership of the mailing list. I cannot > remember whether or not this site will request membership if you are > not already a list member. > > David Cousens > > > On Sun, 2025-02-09 at 20:21 +0900, Bo Buckley wrote: > > In the docs: > > https://wiki.gnucash.org/wiki/GnuCash_Forum > > > > If claims: > > > > > The *GnuCash project* does *not* use ancient *forum* software for > > > its > > > online user support. It uses mailing list technology. > > > > > > I'm completely lost as to the advantage of using a mailing list over > > an > > indexed searchable forum, Github Discussions, or otherwise. In > > particular > > I'm really struggling to find a way to find if my existing issue has > > already been discussed somewhere as the only thing indexed appears to > > be > > bugzilla and the FAQs. > > > > According to the mailing list docs: > > > > > Currently, there is no on-site mechanism to search the mailing > > > lists > > > *and the search link on the archive page is broken.*Instead, use > > > the term > > > "site:lists.gnucash.org" at Google or Yahoo! to search within the > > > archives, e.g. > > > > http://www.google.com/search?q=site%3Alists.gnucash.org+string+to+search > > > > > > > I'm not sure if this worked well at one point, but it definitely does > > not > > work well for me now. See attached screenshot. It appears Google's > > crawler > > somehow finds its way to all the docs and other general content via > > the > > lists.gnucash.org, so it is not filtering out hardly anything as I > > would > > expect. The only alternative approach I can find is to browse (not > > search) > > https://lists.gnucash.org/pipermail/gnucash-user/, which I think > > everyone > > can appreciate to not be an exactly speedy process. > > > > Is there a better way to verify existing discussions/issues > > (including this > > one)? > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > 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 - 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 to Price Database issue with low transactions amounts
Dear John and Jim, Thank you for your replies. Though I'm not sure they solve my problem. Consequently for best results enter the correct amount in the register and > the value in the exchange rate dialog and let GnuCash calculate the > price/exchange rate. > In your example, when importing each transaction and filling out the > Transfer Funds dialogue, I think you will have better results if you > disregard the Exchange Rate field, and concentrate on entering the correct > USD amount for the Expenses:Bank Service Charge account. > Both your answers appear to point to instead of entering an Exchange Rate, to enter the Debit Amount in USD. But in this example, and in most of my real-world scenarios, I don't have this number in USD and would like to use an Exchange Rate to calculate it. The examples in this issue are bank transfer fees that were charged in JPY to my JPY based checking account. I also have bank transfer fees that are charged in other separate USD based checking accounts. I want all bank transfer fee expenses to be within a single USD based expense account. Is this not an expected use case? Regardless, I'm really not understanding the point of the "Transfer Funds" dialog if you can't reliably enter an Exchange Rate. Why have the input Exchange Rate and "Fetch Rate" if it will potentially be silently overridden? Price is calculated when necessary as the ratio amount/value and is rounded > only as needed to be represented by a ratio of two 64-bit integers. > By "Price" here, you are referring to the Price Database entry Currencies:JPY:JPY:Price right? "Amount" is the transaction amount I'm importing in JPY, e.g. 10,000, right? What then is "value" with regards to a GNUcash element? Also how is "when necessary" defined? In my example, I already have a correct Exchange Rate (i.e. Price entry in Price Database) of 0.0066 for 1/29/2025. It would be my assumption that recalculating it would be unnecessary if such a price already exists. Am I misunderstanding something? Price is calculated when necessary as the ratio amount/value and is rounded > only as needed to be represented by a ratio of two 64-bit integers. > Consequently for best results enter the correct amount in the register and > the value in the exchange rate dialog and let GnuCash calculate the > price/exchange rate. > @John Ralls, would you be able to point to where in the codebase this is handled (i.e. where the Exchange Rate from the Transfer Funds Dialog is taken and how the Price Database entry Price is calculated?) I'd understand a lot better seeing the code. Otherwise I'm lost on why this has to be left as a known rounding error and cannot be handled some other way. This is an incorrect expectation. GnuCash does not behave this way. > Exchange rates used in transactions might get saved to the Price Database, > but as John said, there is only one entry per calendar day. Different rates > on the same day will overwrite preceding rates. I think this is just a misunderstanding of what I was trying to say. I understand that there is only one price per day, and all will be overwritten; this seems reasonable to me and not unexpected. > Exchange rates from the Price database might get used as the default value > in the Transfer Funds dialogue, but what you enter there will take > precedence. This is precisely the problem I'm trying to point out, it doesn't seem to take precedence. Compare the values in my csv/table provided for the columns ExchangeRateGivenInTransferFundsDialog and ExchangeRateRecordedInPriceDatabase. There you will see that despite entering 0.0066 for all Exchange Rates in the dialogue, the actual recorded Price (i.e. exchange rate) varies unexpectedly when recorded to the Price Database. I'm also now seeing this noted in the docs at https://gnucash.org/docs/v5//C/gnucash-guide/currency_trading_accts.html: Whereas if Exchange Rate is selected and entered, the exact value is not > often recorded due to the rounding errors. > > Not quite rounding error. The conceptual mistake is to treat the exchange > rate as fundamental. It is not. It is merely the ratio of value in currency > A to value in currency B. AFAIK GnuCash does not even store that ratio. It > is the values in the two currencies which are fundamental. I may be misunderstanding something, but aren't those the same thing? I.e. 0.0066 USD * ExchangeRate = 1 JPY. The ratio of 0.0066 USD / 1 JPY is the Exchange Rate, which is what is stored in the Price Database, no? If not, then what are you referring to specifically when you say "value" as it pertains to a GNUcash element? Thanks again in advance! On Mon, Feb 10, 2025 at 7:09 AM wrote: > Bo: > > Thank you for a good question! > > John Ralls already gave you an answer, and it is correct. John writes > the code, he knows whereof he speaks. But let me try to explain it a > different way. > > On 2025-02-09 04:36, Bo Buckley wrote: > > ...I recently tried to add a JPY checking account to my book
Re: [GNC] Searching mailing lists
https://wiki.gnucash.org/wiki/Mailing_Lists David T. On Feb 10, 2025, 8:23 AM, at 8:23 AM, David Cousens wrote: >I am not sure what the official position is re the mail archive site. >AFAIK it mirrors posts to the official lists which are maintained by >the GnuCash team and moderated by Liz. I just find it much easier to >locate posts and threads on the mail archive site that in the official >mailing lists. > >david Cousens > > >On Mon, 2025-02-10 at 11:34 +0900, Bo Buckley wrote: >> Thank you for the links David. That is helpful. Is this link not >> listed in the docs anywhere? If not, are you not seeing a bunch of >> duplicate questions in the mailing lists? Seems like having a clearly >> explained method for searching for duplicates would be of somewhat >> high priority to keep the lists from being overwhelming. >> >> I didn't see any response from Liz though. Still confused on how this >> email list is supposed to work if I'm not seeing all replies to my >> question. >> >> Thanks again >> >> On Mon, Feb 10, 2025 at 11:21 AM David Cousens >> wrote: >> > >> > As well as the method Liz mentioned it is also possible to access >> > and >> > search the mailing list archives at >> > >> > https://www.mail-archive.com/gnucash-user@gnucash.org/ >> > >> > https://www.mail-archive.com/gnucash-devel@gnucash.org/ >> > >> > You need to have existing membership of the mailing list. I cannot >> > remember whether or not this site will request membership if you >> > are >> > not already a list member. >> > >> > David Cousens >> > >> > >> > On Sun, 2025-02-09 at 20:21 +0900, Bo Buckley wrote: >> > > In the docs: >> > > https://wiki.gnucash.org/wiki/GnuCash_Forum >> > > >> > > If claims: >> > > >> > > > The *GnuCash project* does *not* use ancient *forum* software >> > for >> > > > its >> > > > online user support. It uses mailing list technology. >> > > >> > > >> > > I'm completely lost as to the advantage of using a mailing list >> > over >> > > an >> > > indexed searchable forum, Github Discussions, or otherwise. In >> > > particular >> > > I'm really struggling to find a way to find if my existing issue >> > has >> > > already been discussed somewhere as the only thing indexed >> > appears to >> > > be >> > > bugzilla and the FAQs. >> > > >> > > According to the mailing list docs: >> > > >> > > > Currently, there is no on-site mechanism to search the mailing >> > > > lists >> > > > *and the search link on the archive page is broken.*Instead, >> > use >> > > > the term >> > > > "site:lists.gnucash.org" at Google or Yahoo! to search within >> > the >> > > > archives, e.g. >> > > > >> > >http://www.google.com/search?q=site%3Alists.gnucash.org+string+to+search >> > > > >> > > >> > > I'm not sure if this worked well at one point, but it definitely >> > does >> > > not >> > > work well for me now. See attached screenshot. It appears >> > Google's >> > > crawler >> > > somehow finds its way to all the docs and other general content >> > via >> > > the >> > > lists.gnucash.org, so it is not filtering out hardly anything as >> > I >> > > would >> > > expect. The only alternative approach I can find is to browse >> > (not >> > > search) >> > > https://lists.gnucash.org/pipermail/gnucash-user/, which I think >> > > everyone >> > > can appreciate to not be an exactly speedy process. >> > > >> > > Is there a better way to verify existing discussions/issues >> > > (including this >> > > one)? >> > > ___ >> > > gnucash-user mailing list >> > > gnucash-user@gnucash.org >> > > To update your subscription preferences or to unsubscribe: >> > > https://lists.gnucash.org/mailman/listinfo/gnucash-user >> > > - >> > > 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 >- >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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] confusion on new fields in csv import
David, I was not confused about the reasons for the change in terminology. OP indicated confusion about that change in terminology, and asked how the new terms related to their past experience. I was attempting to provide that connection. I don't use csv much at all with GnuCash, preferring to enter information myself. I'm also not that troubled by the changes in terminology; if it confused me, I'd try a couple of imports in different configurations and note which one worked for me. David T. On Feb 9, 2025, 1:11 PM, at 1:11 PM, David Cousens wrote: >David > >I think the main issue is there is no well defined protocol/standard >for CSV data and the importer does not know where the CSV file >originates and whether the data is presented from the perspective of >the entity which provided the data or that of the entity which has >received the data which makes the use of the terms Debit/Credit and or >Deposit/Withdrawal ambiguous. > >If these terms were used in the internal headers assigned to the >columns of data there would be circumstances in which the header Debit >had to be applied to a column which the source of the file labelled as >Credit a common occurrence with data from Banks for example. > >I think the idea is to provide for maximum flexibility in the use of >the CSV data which means that the user importing the data has to be >cognizant of the origins of the data and the entity for which it was >prepared and the relationship to the entity whose books the data is >being imported into. > >David Cousens > >On Sun, 2025-02-09 at 10:15 +0300, sunfish62--- via gnucash-user wrote: >> Since no one else has stepped in, I'll add my perspective. Please >> bear in mind that I don't use csv imports much. >> >> You originally asked what relationship the new terms had to the old >> ones. >> >> My recollection of the discussions (which take place on gnucash.org, >> not reddit or github, fysa) is that the earlier terminology >> (Deposit/Withdrawal) was ambiguous and would vary depending on the >> account type. Formal accountants in the user group felt that these >> terms should be replaced with more accurate ones. >> >> I don't recall now why the formal accounting terms (Debit/Credit) >> weren't chosen-- but I do know that the option was considered and >> dropped consciously. >> >> The ultimate decision as I recall was to use the Amount/ Amount >> (Negated) terminology as a compromise. I don't recall anything about >> single versus double column csv formats. >> >> To answer your original question, Amount and Amount (Negated) >> correspond to Deposit and Withdrawal. I suspect Transfer Amount and >> Transfer Amount (Negated) are used in different account types and >> also correspond to Deposit and Withdrawal. >> >> Which new entry goes with which old entry I can't say because I don't >> use csv imports and I am not an accountant. I imagine a few trials >> would quickly answer the question, though. >> >> David T. >> >> On Feb 9, 2025, 8:30 AM, at 8:30 AM, Gio Bacareza >> wrote: >> > So I searched more in Reddit and GitHub and it seems that this has >> > not >> > been >> > resolved yet. Here's the summary of my findings if any of you would >> > find it >> > useful. >> > >> > - *May 2023 – rellieberman*: Reported confusion over removal of >> > *Deposit/Withdrawal* fields in CSV import. >> > - *May 2023 – Vincent Dawans, John Ralls*: Discussed renaming >> > *"Amount >> > (Negated)"* to *"Amount (sign-reversed)"* and adding *dynamic >> > labels >> > per >> > account type*. >> > - *May–June 2023 – Community Discussion*: Debated *single-column >> > vs. >> > dual-column support* and whether to use *formal Debit/Credit >> > labels*. >> > - *July 1, 2023 – **dawansv*: moved convo to Bug 798922 - No >> > withdrawal/deposit fields in csv import dialog #1699 and Proposed >> > dynamic >> > column labels based on *base account selection* and UI >> > improvements* >> > commit*: >> > Implemented *dynamic column labels*, added *formal accounting >> > labels*, >> > and >> > updated *import instructions*. >> > - *July 2023 – nomis, flywire, gjanssens*: Suggested keeping >> > *dual-column >> > support* but ensuring *single-column imports work*. >> > - *February 2025 – User Testing (you)*: Found that *single-column >> > "Amount" >> > import does not work*, requiring *dual-column workaround*. >> > - *Current Status*: Feature *not fully functional*; likely >> > *incomplete >> > implementation or a bug*. Bug report recommended. >> > >> > sources https://bugs.gnucash.org/show_bug.cgi?id=798922 and >> > https://github.com/Gnucash/gnucash/pull/1699 >> > >> > On Sun, Feb 9, 2025 at 12:38 PM Gio Bacareza >> > wrote: >> > >> > > Dear Brad and Others, >> > > >> > > Thank you for your response. >> > > >> > > I appreciate the link you provided, but it seems to only discuss >> > > QIF >> > > conversions. While I may consider QIF in the future, I'm >> > > currently >> > looking >> > > for guidance specifica
[GNC] Exchange Rate to Price Database issue with low transactions amounts
Version: 5.9
Build ID: Flathub 5.9
Finance::Quote: 1.63
I recently tried to add a JPY checking account to my books, and import all
the transactions from 2024. Following along with the docs, I was able to
get most transactions to look as expected:
https://lists.gnucash.org/docs/C/gnucash-guide/currency_trading_accts.html
But I noticed all smaller transactions (e.g. wire fees, interest, etc.)
were all being converted incorrectly. To repeat what I am seeing, follow
these steps:
1. Enable Trading Accounts (File -> Properties -> "Use Trading Accounts")
2. Create JPY account "Assets:Current Assets:JapaneseChecking"
3. Open the Price Database in a new window for monitoring the next few steps
4. Import Transactions from a CSV file (see attached test.csv)
5. Assign transactions to this JapaneseChecking account
6. In the "Match Transactions" dialog balance them against "Expenses:Bank
Service Charge" (USD account)
7. Still in the "Match Transactions" dialog, right click with all selected
and "Assign exchange rate". This will initially be associated with the
10,000 JPY transaction if using my test.csv. The first assigned Exchange
Rate will be blank, so "Fetch Rate" (assuming you have your Alpha Vantage
API Key set...I found that quite difficult to discover as the cause of this
silently failing btw).
8. Assuming Fetch Rate succeeds you should now see a new entry in the
"Price Database" under Currencies:JPY for: Date:{Today's Date}, Source:
Finance::Quote, Type:last, Price:0.0066.
9. Press OK back in the "Transfer Funds" window. You will now see a new
entry in the Price Database with: Date 1/29/2025, Source:user:price,
Type:transaction, Price:0.0066 (I would have expected "Fetch Rate" to fetch
the rate listed under "Date" in the Transfer Funds window, not the most
recent rate, but that's another issue).
10. The next transaction (5000 JPY) will now occupy the "Transfer Funds"
window with the previously used Exchange Rate of 0.0066. Press OK
11. The next transaction (2000 JPY) will now occupy the "Transfer Funds"
window with the previously used Exchange Rate of 0.0066. Press OK. You will
now start to see the issue. In the Price Database, the previous entry for
is replaced with Price:0.0065 instead of 0.0066.
12. Keep going, it gets worse. The next transaction (1000 JPY) will now
occupy the "Transfer Funds" window with the previously used Exchange Rate
of 0.0065. Press OK. Now the Price Database entry is replaced with 0.007
13. Keep repeating and you will see the following:
Date Description Transaction Amount ExchangeRateGivenInTransferFundsDialog
ExchangeRateRecordedInPriceDatabase
2025/01/29 Transfer Fee 110 0.0066 0.00909090909090909
2025/01/29 Transfer Fee 150 0.0066 0.00667
2025/01/29 Transfer Fee 200 0.0066 0.005
2025/01/29 Transfer Fee 300 0.0066 0.00667
2025/01/29 Transfer Fee 500 0.0066 0.006
2025/01/29 Transfer Fee 1000 0.0066 0.007
2025/01/29 Transfer Fee 2000 0.0066 0.0065
2025/01/29 Transfer Fee 5000 0.0066 0.0066
2025/01/29 Transfer Fee 1 0.0066 0.0066
My expectation is that whatever is entered into the "Exchange Rate" will be
used and saved into the Price Database. This is not happening. For the
smaller transaction amount (in this example case < 5000 JPY) the Exchange
Rate Recorded in Price Database appears to change on its own accord and not
even linearly. What really stinks is that this all happens silently, so
unless you have the Price Database open and are actively looking at each
new entry, you will be none the wiser to this process completely messing up
the whole Database for Currency:JPY for any dates that had smaller
transactions associated with them.
My only guess is this has to be something to do with a rounding error. So
two summarizing questions:
1. Is this a known bug on bugzilla? I could not find it via a Google
mailinglist search or on bugzilla
2. Is there a known workaround?
I attached a test.gnucash file to illustrate this, though I'm not sure
these mailing lists support attachments.
I would also like to know if there is any better way to streamline
importing a bunch of transactions like this in a foreign currency other
than importing all daily rates from an external source as "user" Price
Database entries via "Import Prices from a CSV file" and pressing OK for
every transaction's "Transfer Funds" dialog. Is there no way to fetch bulk
rates for a year or for all dates listed in the import listed transactions?
I'm also attaching "test.csv" which is the file I use as a test in the
"Import Transactions from a CSV file". The final two columns are not used
in the import, but used to document the issue. Header names should be self
explanatory. Adding contents of csv below in case this mailing list can't
handle attachments.
Date,Description,Transaction
Amount,ExchangeRateGivenInTransferFundsDialog,ExchangeRateRecordedInPriceDatabase
2025/01/29,Transfer Fee,110,0.0066,0.00909090909090909
2025/01/29,Transfer Fee,150,0.0066,0.00667
2025/01/29,Transfe
Re: [GNC] Settings for low-vision users?
The easiest way is to change/lower the resolution on your screen display
(on Windows using Settings/Control Panel, on Mac using System
Settings). This will help not only with GNC, but also all apps on your
computer.
-- ND
On 2/8/25 10:27 PM, David H wrote:
Hi Fred,
You don't say what OS and Gnucash version your wife's friend is using but
I'm going to assume Windows and a recent version of GnuCash :-)
Gnucash uses GTK3 - the following are links from the wiki that relate to
updating GTK settings - if you check them out you'll see there's a bucket
load of settings you can customise.
https://wiki.gnucash.org/wiki/GTK3
https://wiki.gnucash.org/wiki/Configuration_Locations#In_GTK_CONFIG_HOME
If you go to the Help >> About menu on a recent version of Gnucash it will
display 6 or so file locations - the paths are clickable. Mine looks like
the picture below :-
If you click on the 2nd link (GNC_USERCONFIG_DIR) on a Windows pc it
should open your C:\Users\<>\AppData\Roaming\GnuCash folder -
I have a text file named "gtk-3.0.css" in that folder - make sure you don't
add a ".txt" extension to the file. It has the following entry in it to
control the application wide font setting - you can set the font size up or
down until you find a suitable setting. If you change a setting you need
to restart Gnucash to pick up the new settings.
/* Application wide font setting */
* {
font: 24px arial;
}
Hope this helps, Cheers David H.
[image: image.png]
On Sun, 9 Feb 2025 at 02:37, Fred wrote:
My wife is trying to help a friend with low vision get started in GNUCash.
She asked if there is a way to enlarge everything in the GNUCash window
(she is moving from Quicken which, apparently does).
Thanks in advance!
Fred
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
-
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
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Re: [GNC] confusion on new fields in csv import
On 2/9/2025 5:11 AM, David Cousens wrote: David I think the main issue is there is no well defined protocol/standard for CSV data and the importer does not know where the CSV file originates and whether the data is presented from the perspective of the entity which provided the data or that of the entity which has received the data which makes the use of the terms Debit/Credit and or Deposit/Withdrawal ambiguous. If these terms were used in the internal headers assigned to the columns of data there would be circumstances in which the header Debit had to be applied to a column which the source of the file labelled as Credit a common occurrence with data from Banks for example. THIS issue is one of the factors we all should be taking into account when making the decision whether to use the "user friendly" column labels or "formal labels" (just "debit" or "credit"). If using the latter, the only remaining issue is "from whose point of view". If using the former, we have that issue PLUS no reason to suppose the "user friendly" labels will match and that's account type by account type. So IF expecting to be doing lots of importing/exporting another reason to choose to use "formal" Michael D Novack Michael D Novack ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 to Price Database issue with low transactions amounts
The price database contains only one exchange rate per day.
All amounts and values are rounded to the commodity’s minimum fraction, which
is 1 for JPY and .01 for USD.
Each split in a transaction has an amount in the split’s account commodity and
a value in the transaction currency. The transaction currency is determined by
the account of the register in which the transaction is created, even if that
account isn’t used in any of the splits. Only the amount and value are stored.
Price is calculated when necessary as the ratio amount/value and is rounded
only as needed to be represented by a ratio of two 64-bit integers.
Consequently for best results enter the correct amount in the register and the
value in the exchange rate dialog and let GnuCash calculate the price/exchange
rate.
Regards,
John Ralls
> On Feb 9, 2025, at 4:36 AM, Bo Buckley wrote:
>
> Version: 5.9
> Build ID: Flathub 5.9
> Finance::Quote: 1.63
>
> I recently tried to add a JPY checking account to my books, and import all
> the transactions from 2024. Following along with the docs, I was able to
> get most transactions to look as expected:
>
> https://lists.gnucash.org/docs/C/gnucash-guide/currency_trading_accts.html
>
> But I noticed all smaller transactions (e.g. wire fees, interest, etc.)
> were all being converted incorrectly. To repeat what I am seeing, follow
> these steps:
>
> 1. Enable Trading Accounts (File -> Properties -> "Use Trading Accounts")
> 2. Create JPY account "Assets:Current Assets:JapaneseChecking"
> 3. Open the Price Database in a new window for monitoring the next few steps
> 4. Import Transactions from a CSV file (see attached test.csv)
> 5. Assign transactions to this JapaneseChecking account
> 6. In the "Match Transactions" dialog balance them against "Expenses:Bank
> Service Charge" (USD account)
> 7. Still in the "Match Transactions" dialog, right click with all selected
> and "Assign exchange rate". This will initially be associated with the
> 10,000 JPY transaction if using my test.csv. The first assigned Exchange
> Rate will be blank, so "Fetch Rate" (assuming you have your Alpha Vantage
> API Key set...I found that quite difficult to discover as the cause of this
> silently failing btw).
> 8. Assuming Fetch Rate succeeds you should now see a new entry in the
> "Price Database" under Currencies:JPY for: Date:{Today's Date}, Source:
> Finance::Quote, Type:last, Price:0.0066.
> 9. Press OK back in the "Transfer Funds" window. You will now see a new
> entry in the Price Database with: Date 1/29/2025, Source:user:price,
> Type:transaction, Price:0.0066 (I would have expected "Fetch Rate" to fetch
> the rate listed under "Date" in the Transfer Funds window, not the most
> recent rate, but that's another issue).
> 10. The next transaction (5000 JPY) will now occupy the "Transfer Funds"
> window with the previously used Exchange Rate of 0.0066. Press OK
> 11. The next transaction (2000 JPY) will now occupy the "Transfer Funds"
> window with the previously used Exchange Rate of 0.0066. Press OK. You will
> now start to see the issue. In the Price Database, the previous entry for
> is replaced with Price:0.0065 instead of 0.0066.
> 12. Keep going, it gets worse. The next transaction (1000 JPY) will now
> occupy the "Transfer Funds" window with the previously used Exchange Rate
> of 0.0065. Press OK. Now the Price Database entry is replaced with 0.007
> 13. Keep repeating and you will see the following:
>
> Date Description Transaction Amount ExchangeRateGivenInTransferFundsDialog
> ExchangeRateRecordedInPriceDatabase
> 2025/01/29 Transfer Fee 110 0.0066 0.00909090909090909
> 2025/01/29 Transfer Fee 150 0.0066 0.00667
> 2025/01/29 Transfer Fee 200 0.0066 0.005
> 2025/01/29 Transfer Fee 300 0.0066 0.00667
> 2025/01/29 Transfer Fee 500 0.0066 0.006
> 2025/01/29 Transfer Fee 1000 0.0066 0.007
> 2025/01/29 Transfer Fee 2000 0.0066 0.0065
> 2025/01/29 Transfer Fee 5000 0.0066 0.0066
> 2025/01/29 Transfer Fee 1 0.0066 0.0066
>
> My expectation is that whatever is entered into the "Exchange Rate" will be
> used and saved into the Price Database. This is not happening. For the
> smaller transaction amount (in this example case < 5000 JPY) the Exchange
> Rate Recorded in Price Database appears to change on its own accord and not
> even linearly. What really stinks is that this all happens silently, so
> unless you have the Price Database open and are actively looking at each
> new entry, you will be none the wiser to this process completely messing up
> the whole Database for Currency:JPY for any dates that had smaller
> transactions associated with them.
>
> My only guess is this has to be something to do with a rounding error. So
> two summarizing questions:
>
> 1. Is this a known bug on bugzilla? I could not find it via a Google
> mailinglist search or on bugzilla
> 2. Is there a known workaround?
>
> I attached a test.gnucash file to illustrate this, though I'm not sure
>
Re: [GNC] Invoice configuration?
Latest is 5.10. If you built from git then you’ve got whatever was the stable HEAD when you pulled. That might report the version as 5.01+15-gX where is the sha1 hash for whatever commit it was. You can save anything you change in report options as a saved report configuration. To use it you open Reports>Saved Configurations and select the one you want. One of the report options is the stylesheet and you can create a customized one of those too: The CSS stylesheet accepts arbitrary CSS so it’s pretty powerful. With a bit more effort you can change the report code by copying invoice.scm and changing its Scheme code. See https://wiki.gnucash.org/wiki/Custom_Reports. Regards, John Ralls > On Feb 8, 2025, at 1:39 PM, Simon Roberts > wrote: > > Hi all, I'm using GNC 5.15 -- at least I think that's right, I built it > a couple of weeks ago so "latest" :) > > Can I customize the invoice printing configuration? I have to change > the "Display", "Display Columns", and "Layout" manually every time I > prepare an invoice for PDF. Can the configuration I select for these items > be saved? > > I asked this when I was using GNC 4.x and the answer was no, but I'm hoping > this has changed by now? > > Thanks for any pointers! > Cheers, > Simon > > > -- > Simon Roberts > 303 249 3613 > https://www.youtube.com/@DancingCloudServices > https://www.linkedin.com/in/simonhgroberts/ > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Invoice configuration?
Many thanks John (yes, version wise, I'm using 5.5 for my business, and just built the latest for my wife. I guess that's 5.10, add 'em together and ... yeah well, you can tell I wasn't looking at hers at the time I wrote the question) But huge thanks, I am playing with that now and it seems to work very nicely. Cheers, Simon On Sun, Feb 9, 2025 at 10:23 AM John Ralls wrote: > Latest is 5.10. If you built from git then you’ve got whatever was the > stable HEAD when you pulled. That might report the version as > 5.01+15-gX where is the sha1 hash for whatever commit it was. > > You can save anything you change in report options as a saved report > configuration. To use it you open Reports>Saved Configurations and select > the one you want. One of the report options is the stylesheet and you can > create a customized one of those too: The CSS stylesheet accepts arbitrary > CSS so it’s pretty powerful. > > With a bit more effort you can change the report code by copying > invoice.scm and changing its Scheme code. See > https://wiki.gnucash.org/wiki/Custom_Reports. > > Regards, > John Ralls > > > On Feb 8, 2025, at 1:39 PM, Simon Roberts < > si...@dancingcloudservices.com> wrote: > > > > Hi all, I'm using GNC 5.15 -- at least I think that's right, I built it > > a couple of weeks ago so "latest" :) > > > > Can I customize the invoice printing configuration? I have to change > > the "Display", "Display Columns", and "Layout" manually every time I > > prepare an invoice for PDF. Can the configuration I select for these > items > > be saved? > > > > I asked this when I was using GNC 4.x and the answer was no, but I'm > hoping > > this has changed by now? > > > > Thanks for any pointers! > > Cheers, > > Simon > > > > > > -- > > Simon Roberts > > 303 249 3613 > > https://www.youtube.com/@DancingCloudServices > > https://www.linkedin.com/in/simonhgroberts/ > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > Please remember to CC this list on all your replies. > > You can do this by using Reply-To-List or Reply-All. > > -- Simon Roberts 303 249 3613 https://www.youtube.com/@DancingCloudServices https://www.linkedin.com/in/simonhgroberts/ ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] confusion on new fields in csv import
I had to experiment with the fields to find that amount negated worked the best for me. Make a copy of your file and run experiments using the different amount fields to see what happens. Once you find a setup that works for you, switch back to your production file and move forward. On Sat, Feb 8, 2025, 20:39 Gio Bacareza wrote: > Dear Brad and Others, > > Thank you for your response. > > I appreciate the link you provided, but it seems to only discuss QIF > conversions. While I may consider QIF in the future, I'm currently looking > for guidance specifically on the new CSV import fields in GnuCash 5.10. > > I've used CSV import successfully in the past. However, the recent update > introduced new terminology (Amount, Amount (Negated), Transfer Amount, > Transfer Amount (Negated)) that I'm struggling to understand in relation to > my previous CSV structure. > > I have already searched the GnuCash documentation and wikis, but I haven't > found any information about these new terms. The documentation still seems > to refer to the old "Withdrawal" and "Deposit" fields. > > For example from > https://www.gnucash.org/viewdoc.phtml?rev=5&lang=C&doc=help, > this is what it says: > > """ > > The dropdown list of *GnuCash* transaction data fields which may be > associated with a column of the imported data contains the following: > >- > >*None*: The column is not assigned to a transaction data field and is >not imported; >- > >*Date*: Ensure the date format in the column matches the Miscellaneous >date Format Setting; >- > >*Num*: Transaction Num field - Use for check numbers etc.; >- > >*Description*; >- > >*Notes*; >- > >*Transaction Commodity*; >- > >*Void Reason*; >- > >*Action*; >- > >*Account*: This header should be matched to a column specifying the >source account for a transaction if it is present. Otherwise, set the >source account in the *Account* combo box; >- > >*Deposit*: Apply this header to a column containing the amount of the >transaction. Positive amounts in the column generally represent an > increase >in the account balance and negative amounts a decrease in the balance >(asset accounts: Checking, Savings). In external statements supplied by > a >bank for a check or savings account, a credit (Cr) is normally an > increase >in the account balance and a debit (Dr) a decrease in the account > balance. >In the banks eyes, your savings or checking account is a Liability to > them; > >If the amount data is in separate columns for debits and credits you >will have to apply both this heading and the Withdrawal heading. >- > >*Withdrawal*: Apply this header to a column with the amount of the >transaction where positive amounts in the column represent a decrease in >the account balance and negative amounts an increase in the balance > (e.g. >Liability account: credit card). > > """ > And from > https://www.gnucash.org/docs/v5/C/gnucash-manual/trans-import.html#idm6675 > : > """ > > The import panel shows the data being imported as it is interpreted using > the settings chosen to define columns and formats. The dropdown lists in > the headers for each column of the import allow you to associate a specific > column in the imported data with a specific field in the display of a > transaction in an account register. At a minimum to import data, columns in > the imported data containing the following information *must* be specified: > >- > >*Date*: of transaction; >- > >*Account*: into which transaction is to be imported (or alternatively >set the base account as above); >- > >*Description*: of the transaction; >- > >*Deposit or Withdrawal*: column. > > """ > > There is no mention at all of the new terms: *Amount, Amount (Negated), > Transfer Amount, Transfer Amount (Negated)* > > I would be grateful if you could provide clarification on the new CSV field > names and how they should be used. > > By the way, I'm on MacOS Sequoia 15.3 > > Sincerely, > Gio > > > > On Sat, Feb 8, 2025 at 7:57 PM Brad Morrison > wrote: > > > Hi Gio/GNUCash users, > > > > https://wiki.gnucash.org/wiki/FAQ#Importing.2FExporting_Data - here is > > the FAQ section on importing & exporting data, you could also try > > searching the GnuCash Wiki for more information for "CSV" > > > > In addition, which operating system are you using? > > > > --- > > Thanks, > > > > Brad - https://www.facebook.com/brad.morrison.12327/ & > > https://nextdoor.com/profile/01mP46jj8KCzj3sP4 & > > https://norcal.social/@BradMorrison > > > > On 2025-02-07 22:04, Gio Bacareza wrote: > > > > > Dear GnuCash Community, > > > > > > I recently upgraded GnuCash on my Mac to Version 5.10 and noticed a > > > significant change in the CSV import feature. The "Deposit" and > > > "Withdrawal" fields have been replaced with "Amount," "Amount > (Negated)," > > > "Transfer Amount," and "T
