Re: [GNC] Switching to trading accounts in existing database
Hi Mike, Lukas, I am using trading accounts since multiple years and can confirm that the UI can be pretty cumbersome. I got used to it. Besides the regular problems in getting the transactions straight it works pretty well Cheers, Christoph > Am 22.01.2021 um 06:13 schrieb Mike Alexander : > > When I implemented trading accounts several years ago they were a bit > controversial. Some people thought they were more trouble than they were > worth and argued that they should be an opt-in choice. One of the initial > design goals was that if you didn't turn them on nothing would change in the > way GnuCash behaved. The initial implementation had some rough edges too, > which didn't help. It's been a while since any significant problems have > come up with them (although a new bug was filed on them today) so maybe this > question should be revisited. > > It's also the case that the user interface leaves a bit to be desired. It is > harder than it should be to enter multi-currency transactions with trading > accounts turned on. At the time I implemented them there was an effort > underway to rewrite the code that supports the register UI and the new > implementation would have improved this. Unfortunately that effort was later > abandoned and we're left with the old UI code. I have ideas for how to > improve it, but my time and ability to do much coding is limited these days > so I probably won't get to it soon. See > https://bugs.gnucash.org/show_bug.cgi?id=797913 for more information about > this. > > I know what you mean about multiple currencies. I haven't moved around as > often as you have, but I've lived in a couple of countries and spend a lot of > time traveling in various others. I think I have accounts in nearly 30 > currencies over a 30 year period. I used to have income and expense accounts > in multiple currencies, but this turned out to not work well so I now use > only one currency for all of them and convert transactions in other > currencies into USD. This works for me since it is still my home currency > although I am under increasing pressure to move to Canada. > > Mike > > On 21 Jan 2021, at 21:06, Lukas Haase wrote: > >> Hi Christopher, >> >> This is very sad. Sad for various reasons. >> >> I went over these documents previously (but did not read them thoroughly). >> >> My takeaway is: >> * Storing the conversion rate per transaction makes the accounting equation >> as a function of time inconsistent (but it is consistent for each snaphot in >> time). >> * Trading account accounts for these inaccuracies. >> >> My question was more why the trading accounts (which seem to me the cleaner, >> superior and better way) are not enabled by default. >> >> Also, can you comment a bit more why precicely this would be a major >> minefield? (If you know it, of course). >> >> Multiple databases are just extremely hard for some people (like me). >> >> Consider living for a couple of months to a year in a different place. There >> is just no way to separate this in a clean way without replicating all the >> transactions in different databases. BTDT. >> >> Also I moved multiple times. Even then, there is no clear cut: Initially I >> would use credit cards, ATM etc. from previous country. Even the first or >> second rent may be partially paid with funds from the previous location. It >> takes a few months until I could consider the books between two countries >> sufficiently separate. The only ways are a) Massive transaction Replication >> b) booking everything I pay with funds from old country into old database. >> But with my rent example, it gets very inconsistent how much I paid rent at >> the new place. >> >> Lastly, simple portfolio accounting (e.g. crypto currencies) if they are >> bought in different countries. >> >> I am curious what the potential mines are so I can try to avoid them. >> >> Lukas >> >> >> >> On 2021-01-21 20:20, Christopher Lam wrote: >>> Multicurrency is a major minefield. >>> Start from https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html >>> and finish with >>> https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the >>> background on trading accounts. >>> From discussion with accountant, it would seem that the safest approach is >>> to have 1 book per home currency. When you move countries you'd be better >>> off with a new book with a new home currency. Taking temporary trips abroad >>> gets the currencies translated to home currency. AFAIU. IANAA YMMV. >>> https://techcrunch.com/2010/08/14/internet-must-be-true/ >>> >>> On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: >>> Hi Mike, On 2021-01-21 02:24, Mike Alexander wrote: > On 19 Jan 2021, at 20:08, Lukas Haase wrote: > >> So I got recommended using trading accounts. But suddenly all my >> previous multi-currency transactions get a small grey box with a cross >> (hinting the transaction is
Re: [GNC] Switching to trading accounts in existing database
Personally I'd stick with 1 book = 1 currency, and record all transactions in their home currency only. I'd only record the same transaction in both books if they're a formal currency transfer. A simple issue is balance sheet: if you hold stocks eg TSLA in your USD account, and ANA from your Japan account... the overall balance sheet in USD will convert ANA->JPY->USD. This has a chance of being accurate if you have *daily* USD/JPY prices. Most users don't. On Fri, 22 Jan 2021 at 02:06, Lukas Haase wrote: > Hi Christopher, > > This is very sad. Sad for various reasons. > > I went over these documents previously (but did not read them thoroughly). > > My takeaway is: > * Storing the conversion rate per transaction makes the accounting > equation as a function of time inconsistent (but it is consistent for > each snaphot in time). > * Trading account accounts for these inaccuracies. > > My question was more why the trading accounts (which seem to me the > cleaner, superior and better way) are not enabled by default. > > Also, can you comment a bit more why precicely this would be a major > minefield? (If you know it, of course). > > Multiple databases are just extremely hard for some people (like me). > > Consider living for a couple of months to a year in a different place. > There is just no way to separate this in a clean way without replicating > all the transactions in different databases. BTDT. > > Also I moved multiple times. Even then, there is no clear cut: Initially > I would use credit cards, ATM etc. from previous country. Even the first > or second rent may be partially paid with funds from the previous > location. It takes a few months until I could consider the books between > two countries sufficiently separate. The only ways are a) Massive > transaction Replication b) booking everything I pay with funds from old > country into old database. But with my rent example, it gets very > inconsistent how much I paid rent at the new place. > > Lastly, simple portfolio accounting (e.g. crypto currencies) if they are > bought in different countries. > > I am curious what the potential mines are so I can try to avoid them. > > Lukas > > > > On 2021-01-21 20:20, Christopher Lam wrote: > > Multicurrency is a major minefield. > > Start from > https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html > > and finish with > > https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the > > background on trading accounts. > > From discussion with accountant, it would seem that the safest approach > is > > to have 1 book per home currency. When you move countries you'd be better > > off with a new book with a new home currency. Taking temporary trips > abroad > > gets the currencies translated to home currency. AFAIU. IANAA YMMV. > > https://techcrunch.com/2010/08/14/internet-must-be-true/ > > > > On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: > > > >> Hi Mike, > >> > >> On 2021-01-21 02:24, Mike Alexander wrote: > >>> On 19 Jan 2021, at 20:08, Lukas Haase wrote: > >>> > So I got recommended using trading accounts. But suddenly all my > previous multi-currency transactions get a small grey box with a cross > (hinting the transaction is inconsistent). > > How do I best deal with this? > Is it possible to keep my old multi currency transactions as-is and > use trading accounts only for securities/stocks? > > If not, how do I migrate while ensuring my ten years worth of data > does not suddenly get inconsistent? > >>> > >>> You should be able to use the "Check & Repair" commands in the Actions > >>> menu to add the trading account splits to existing transactions. I > >>> would certainly save a copy of my data before doing this, and try it on > >>> a few transactions first. Your situation is complex enough that it is > >>> not unlikely that this won't do exactly what you want, but it's worth a > >>> try assuming you have good backup. > >> > >> Thank you, I think that worked indeed. > >> > >> I still need to cross-check everything (at the first glance things look > >> OK). > >> > >> So then I'd have a general question on the multi currency feature: > >> > >> 1.) Are "Trading Accounts" just an *alternative* way to handle multi > >> currencies (and as such have nothing to do with "trading")? > >> > >> 2.) Trading Account seem to be way more powerful than storing the > >> exchange rate in each transaction > >> > >> 3.) Why exactly aren't they enabled by default if they are so superior? > >> Why let people my default use the way that makes things less consistent > >> and error-prone? > >> > >> Thanks, > >> Lukas > >> > >> > >> > >> > >> ___ > >> 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 > >>
Re: [GNC] Switching to trading accounts in existing database
The issue is when currency fluctuates, you have capital gains or losses, depending on whatever you consider to be your home currency. These gains/losses are unrecorded (but not unrealised). C On Fri, 22 Jan 2021 at 04:36, w...@theprescotts.com wrote: > I am probably missing something here. > > I have bank accounts in two countries and regularly transfer money between > them. Whenever I move money, I record the transaction and the amount for > each side of the transaction. Gnucash automatically makes an entry in the > Price Database recording the conversion rate. > > It seems much cleaner than treating one currency or the other as a > commodity that is bought or sold at some rate. One thing that is a little > strange is that the Price Database has separate tables for each direction. > I suppose it depends on which side of the transaction I use to record the > transfer. But I almost never look at the Price Database so it doesn't > bother me much. > > Will > > On 2021 Jan 21, at 01-21 20:06:04, Lukas Haase wrote: > > Hi Christopher, > > This is very sad. Sad for various reasons. > > I went over these documents previously (but did not read them thoroughly). > > My takeaway is: > * Storing the conversion rate per transaction makes the accounting > equation as a function of time inconsistent (but it is consistent for each > snaphot in time). > * Trading account accounts for these inaccuracies. > > My question was more why the trading accounts (which seem to me the > cleaner, superior and better way) are not enabled by default. > > Also, can you comment a bit more why precicely this would be a major > minefield? (If you know it, of course). > > Multiple databases are just extremely hard for some people (like me). > > Consider living for a couple of months to a year in a different place. > There is just no way to separate this in a clean way without replicating > all the transactions in different databases. BTDT. > > Also I moved multiple times. Even then, there is no clear cut: Initially I > would use credit cards, ATM etc. from previous country. Even the first or > second rent may be partially paid with funds from the previous location. It > takes a few months until I could consider the books between two countries > sufficiently separate. The only ways are a) Massive transaction Replication > b) booking everything I pay with funds from old country into old database. > But with my rent example, it gets very inconsistent how much I paid rent at > the new place. > > Lastly, simple portfolio accounting (e.g. crypto currencies) if they are > bought in different countries. > > I am curious what the potential mines are so I can try to avoid them. > > Lukas > > > > On 2021-01-21 20:20, Christopher Lam wrote: > > Multicurrency is a major minefield. > > Start from > https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html > > and finish with > > https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the > > background on trading accounts. > > From discussion with accountant, it would seem that the safest approach > is > > to have 1 book per home currency. When you move countries you'd be better > > off with a new book with a new home currency. Taking temporary trips > abroad > > gets the currencies translated to home currency. AFAIU. IANAA YMMV. > > https://techcrunch.com/2010/08/14/internet-must-be-true/ > > On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: > >> Hi Mike, > >> > >> On 2021-01-21 02:24, Mike Alexander wrote: > >>> On 19 Jan 2021, at 20:08, Lukas Haase wrote: > >>> > So I got recommended using trading accounts. But suddenly all my > previous multi-currency transactions get a small grey box with a cross > (hinting the transaction is inconsistent). > > How do I best deal with this? > Is it possible to keep my old multi currency transactions as-is and > use trading accounts only for securities/stocks? > > If not, how do I migrate while ensuring my ten years worth of data > does not suddenly get inconsistent? > >>> > >>> You should be able to use the "Check & Repair" commands in the Actions > >>> menu to add the trading account splits to existing transactions. I > >>> would certainly save a copy of my data before doing this, and try it on > >>> a few transactions first. Your situation is complex enough that it is > >>> not unlikely that this won't do exactly what you want, but it's worth a > >>> try assuming you have good backup. > >> > >> Thank you, I think that worked indeed. > >> > >> I still need to cross-check everything (at the first glance things look > >> OK). > >> > >> So then I'd have a general question on the multi currency feature: > >> > >> 1.) Are "Trading Accounts" just an *alternative* way to handle multi > >> currencies (and as such have nothing to do with "trading")? > >> > >> 2.) Trading Account seem to be way more powerful than storing the > >> exchange rate in each transaction > >> > >> 3.) Why exactly aren't they
Re: [GNC] Switching to trading accounts in existing database
When I implemented trading accounts several years ago they were a bit controversial. Some people thought they were more trouble than they were worth and argued that they should be an opt-in choice. One of the initial design goals was that if you didn't turn them on nothing would change in the way GnuCash behaved. The initial implementation had some rough edges too, which didn't help. It's been a while since any significant problems have come up with them (although a new bug was filed on them today) so maybe this question should be revisited. It's also the case that the user interface leaves a bit to be desired. It is harder than it should be to enter multi-currency transactions with trading accounts turned on. At the time I implemented them there was an effort underway to rewrite the code that supports the register UI and the new implementation would have improved this. Unfortunately that effort was later abandoned and we're left with the old UI code. I have ideas for how to improve it, but my time and ability to do much coding is limited these days so I probably won't get to it soon. See https://bugs.gnucash.org/show_bug.cgi?id=797913 for more information about this. I know what you mean about multiple currencies. I haven't moved around as often as you have, but I've lived in a couple of countries and spend a lot of time traveling in various others. I think I have accounts in nearly 30 currencies over a 30 year period. I used to have income and expense accounts in multiple currencies, but this turned out to not work well so I now use only one currency for all of them and convert transactions in other currencies into USD. This works for me since it is still my home currency although I am under increasing pressure to move to Canada. Mike On 21 Jan 2021, at 21:06, Lukas Haase wrote: Hi Christopher, This is very sad. Sad for various reasons. I went over these documents previously (but did not read them thoroughly). My takeaway is: * Storing the conversion rate per transaction makes the accounting equation as a function of time inconsistent (but it is consistent for each snaphot in time). * Trading account accounts for these inaccuracies. My question was more why the trading accounts (which seem to me the cleaner, superior and better way) are not enabled by default. Also, can you comment a bit more why precicely this would be a major minefield? (If you know it, of course). Multiple databases are just extremely hard for some people (like me). Consider living for a couple of months to a year in a different place. There is just no way to separate this in a clean way without replicating all the transactions in different databases. BTDT. Also I moved multiple times. Even then, there is no clear cut: Initially I would use credit cards, ATM etc. from previous country. Even the first or second rent may be partially paid with funds from the previous location. It takes a few months until I could consider the books between two countries sufficiently separate. The only ways are a) Massive transaction Replication b) booking everything I pay with funds from old country into old database. But with my rent example, it gets very inconsistent how much I paid rent at the new place. Lastly, simple portfolio accounting (e.g. crypto currencies) if they are bought in different countries. I am curious what the potential mines are so I can try to avoid them. Lukas On 2021-01-21 20:20, Christopher Lam wrote: Multicurrency is a major minefield. Start from https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html and finish with https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the background on trading accounts. From discussion with accountant, it would seem that the safest approach is to have 1 book per home currency. When you move countries you'd be better off with a new book with a new home currency. Taking temporary trips abroad gets the currencies translated to home currency. AFAIU. IANAA YMMV. https://techcrunch.com/2010/08/14/internet-must-be-true/ On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: Hi Mike, On 2021-01-21 02:24, Mike Alexander wrote: On 19 Jan 2021, at 20:08, Lukas Haase wrote: So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? You should be able to use the "Check & Repair" commands in the Actions menu to add the trading account splits to existing transactions. I would certainly save a copy of my data before doing this, and try it on a few transactions first. Your situation is complex enough that it is not
Re: [GNC] Switching to trading accounts in existing database
https://www.accaglobal.com/us/en/technical-activities/technical-resources-search/2015/march/frs102-foreign-currency-translation.html This is all I can offer in supporting information. Experienced users can undoubtedly offer more. On Fri, 22 Jan 2021, 12:36 pm w...@theprescotts.com, wrote: > I am probably missing something here. > > I have bank accounts in two countries and regularly transfer money between > them. Whenever I move money, I record the transaction and the amount for > each side of the transaction. Gnucash automatically makes an entry in the > Price Database recording the conversion rate. > > It seems much cleaner than treating one currency or the other as a > commodity that is bought or sold at some rate. One thing that is a little > strange is that the Price Database has separate tables for each direction. > I suppose it depends on which side of the transaction I use to record the > transfer. But I almost never look at the Price Database so it doesn't > bother me much. > > Will > > On 2021 Jan 21, at 01-21 20:06:04, Lukas Haase wrote: > > Hi Christopher, > > This is very sad. Sad for various reasons. > > I went over these documents previously (but did not read them thoroughly). > > My takeaway is: > * Storing the conversion rate per transaction makes the accounting > equation as a function of time inconsistent (but it is consistent for each > snaphot in time). > * Trading account accounts for these inaccuracies. > > My question was more why the trading accounts (which seem to me the > cleaner, superior and better way) are not enabled by default. > > Also, can you comment a bit more why precicely this would be a major > minefield? (If you know it, of course). > > Multiple databases are just extremely hard for some people (like me). > > Consider living for a couple of months to a year in a different place. > There is just no way to separate this in a clean way without replicating > all the transactions in different databases. BTDT. > > Also I moved multiple times. Even then, there is no clear cut: Initially I > would use credit cards, ATM etc. from previous country. Even the first or > second rent may be partially paid with funds from the previous location. It > takes a few months until I could consider the books between two countries > sufficiently separate. The only ways are a) Massive transaction Replication > b) booking everything I pay with funds from old country into old database. > But with my rent example, it gets very inconsistent how much I paid rent at > the new place. > > Lastly, simple portfolio accounting (e.g. crypto currencies) if they are > bought in different countries. > > I am curious what the potential mines are so I can try to avoid them. > > Lukas > > > > On 2021-01-21 20:20, Christopher Lam wrote: > > Multicurrency is a major minefield. > > Start from > https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html > > and finish with > > https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the > > background on trading accounts. > > From discussion with accountant, it would seem that the safest approach > is > > to have 1 book per home currency. When you move countries you'd be better > > off with a new book with a new home currency. Taking temporary trips > abroad > > gets the currencies translated to home currency. AFAIU. IANAA YMMV. > > https://techcrunch.com/2010/08/14/internet-must-be-true/ > > On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: > >> Hi Mike, > >> > >> On 2021-01-21 02:24, Mike Alexander wrote: > >>> On 19 Jan 2021, at 20:08, Lukas Haase wrote: > >>> > So I got recommended using trading accounts. But suddenly all my > previous multi-currency transactions get a small grey box with a cross > (hinting the transaction is inconsistent). > > How do I best deal with this? > Is it possible to keep my old multi currency transactions as-is and > use trading accounts only for securities/stocks? > > If not, how do I migrate while ensuring my ten years worth of data > does not suddenly get inconsistent? > >>> > >>> You should be able to use the "Check & Repair" commands in the Actions > >>> menu to add the trading account splits to existing transactions. I > >>> would certainly save a copy of my data before doing this, and try it on > >>> a few transactions first. Your situation is complex enough that it is > >>> not unlikely that this won't do exactly what you want, but it's worth a > >>> try assuming you have good backup. > >> > >> Thank you, I think that worked indeed. > >> > >> I still need to cross-check everything (at the first glance things look > >> OK). > >> > >> So then I'd have a general question on the multi currency feature: > >> > >> 1.) Are "Trading Accounts" just an *alternative* way to handle multi > >> currencies (and as such have nothing to do with "trading")? > >> > >> 2.) Trading Account seem to be way more powerful than storing the > >> exchange rate in each transaction >
Re: [GNC] Switching to trading accounts in existing database
I am probably missing something here. I have bank accounts in two countries and regularly transfer money between them. Whenever I move money, I record the transaction and the amount for each side of the transaction. Gnucash automatically makes an entry in the Price Database recording the conversion rate. It seems much cleaner than treating one currency or the other as a commodity that is bought or sold at some rate. One thing that is a little strange is that the Price Database has separate tables for each direction. I suppose it depends on which side of the transaction I use to record the transfer. But I almost never look at the Price Database so it doesn't bother me much. Will On 2021 Jan 21, at 01-21 20:06:04, Lukas Haase wrote: Hi Christopher, This is very sad. Sad for various reasons. I went over these documents previously (but did not read them thoroughly). My takeaway is: * Storing the conversion rate per transaction makes the accounting equation as a function of time inconsistent (but it is consistent for each snaphot in time). * Trading account accounts for these inaccuracies. My question was more why the trading accounts (which seem to me the cleaner, superior and better way) are not enabled by default. Also, can you comment a bit more why precicely this would be a major minefield? (If you know it, of course). Multiple databases are just extremely hard for some people (like me). Consider living for a couple of months to a year in a different place. There is just no way to separate this in a clean way without replicating all the transactions in different databases. BTDT. Also I moved multiple times. Even then, there is no clear cut: Initially I would use credit cards, ATM etc. from previous country. Even the first or second rent may be partially paid with funds from the previous location. It takes a few months until I could consider the books between two countries sufficiently separate. The only ways are a) Massive transaction Replication b) booking everything I pay with funds from old country into old database. But with my rent example, it gets very inconsistent how much I paid rent at the new place. Lastly, simple portfolio accounting (e.g. crypto currencies) if they are bought in different countries. I am curious what the potential mines are so I can try to avoid them. Lukas On 2021-01-21 20:20, Christopher Lam wrote: > Multicurrency is a major minefield. > Start from https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html > and finish with > https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the > background on trading accounts. > From discussion with accountant, it would seem that the safest approach is > to have 1 book per home currency. When you move countries you'd be better > off with a new book with a new home currency. Taking temporary trips abroad > gets the currencies translated to home currency. AFAIU. IANAA YMMV. > https://techcrunch.com/2010/08/14/internet-must-be-true/ > On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: >> Hi Mike, >> >> On 2021-01-21 02:24, Mike Alexander wrote: >>> On 19 Jan 2021, at 20:08, Lukas Haase wrote: >>> So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? >>> >>> You should be able to use the "Check & Repair" commands in the Actions >>> menu to add the trading account splits to existing transactions. I >>> would certainly save a copy of my data before doing this, and try it on >>> a few transactions first. Your situation is complex enough that it is >>> not unlikely that this won't do exactly what you want, but it's worth a >>> try assuming you have good backup. >> >> Thank you, I think that worked indeed. >> >> I still need to cross-check everything (at the first glance things look >> OK). >> >> So then I'd have a general question on the multi currency feature: >> >> 1.) Are "Trading Accounts" just an *alternative* way to handle multi >> currencies (and as such have nothing to do with "trading")? >> >> 2.) Trading Account seem to be way more powerful than storing the >> exchange rate in each transaction >> >> 3.) Why exactly aren't they enabled by default if they are so superior? >> Why let people my default use the way that makes things less consistent >> and error-prone? >> >> Thanks, >> Lukas >> >> >> >> >> ___ >> 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
Re: [GNC] Switching to trading accounts in existing database
Hi Christopher, This is very sad. Sad for various reasons. I went over these documents previously (but did not read them thoroughly). My takeaway is: * Storing the conversion rate per transaction makes the accounting equation as a function of time inconsistent (but it is consistent for each snaphot in time). * Trading account accounts for these inaccuracies. My question was more why the trading accounts (which seem to me the cleaner, superior and better way) are not enabled by default. Also, can you comment a bit more why precicely this would be a major minefield? (If you know it, of course). Multiple databases are just extremely hard for some people (like me). Consider living for a couple of months to a year in a different place. There is just no way to separate this in a clean way without replicating all the transactions in different databases. BTDT. Also I moved multiple times. Even then, there is no clear cut: Initially I would use credit cards, ATM etc. from previous country. Even the first or second rent may be partially paid with funds from the previous location. It takes a few months until I could consider the books between two countries sufficiently separate. The only ways are a) Massive transaction Replication b) booking everything I pay with funds from old country into old database. But with my rent example, it gets very inconsistent how much I paid rent at the new place. Lastly, simple portfolio accounting (e.g. crypto currencies) if they are bought in different countries. I am curious what the potential mines are so I can try to avoid them. Lukas On 2021-01-21 20:20, Christopher Lam wrote: Multicurrency is a major minefield. Start from https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html and finish with https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the background on trading accounts. From discussion with accountant, it would seem that the safest approach is to have 1 book per home currency. When you move countries you'd be better off with a new book with a new home currency. Taking temporary trips abroad gets the currencies translated to home currency. AFAIU. IANAA YMMV. https://techcrunch.com/2010/08/14/internet-must-be-true/ On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: Hi Mike, On 2021-01-21 02:24, Mike Alexander wrote: On 19 Jan 2021, at 20:08, Lukas Haase wrote: So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? You should be able to use the "Check & Repair" commands in the Actions menu to add the trading account splits to existing transactions. I would certainly save a copy of my data before doing this, and try it on a few transactions first. Your situation is complex enough that it is not unlikely that this won't do exactly what you want, but it's worth a try assuming you have good backup. Thank you, I think that worked indeed. I still need to cross-check everything (at the first glance things look OK). So then I'd have a general question on the multi currency feature: 1.) Are "Trading Accounts" just an *alternative* way to handle multi currencies (and as such have nothing to do with "trading")? 2.) Trading Account seem to be way more powerful than storing the exchange rate in each transaction 3.) Why exactly aren't they enabled by default if they are so superior? Why let people my default use the way that makes things less consistent and error-prone? Thanks, Lukas ___ 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. ___ 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
Re: [GNC] Switching to trading accounts in existing database
Multicurrency is a major minefield. Start from https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html and finish with https://www.mathstat.dal.ca/~selinger/accounting/gnucash.html for the background on trading accounts. >From discussion with accountant, it would seem that the safest approach is to have 1 book per home currency. When you move countries you'd be better off with a new book with a new home currency. Taking temporary trips abroad gets the currencies translated to home currency. AFAIU. IANAA YMMV. https://techcrunch.com/2010/08/14/internet-must-be-true/ On Fri, 22 Jan 2021 at 00:59, Lukas Haase wrote: > Hi Mike, > > On 2021-01-21 02:24, Mike Alexander wrote: > > On 19 Jan 2021, at 20:08, Lukas Haase wrote: > > > >> So I got recommended using trading accounts. But suddenly all my > >> previous multi-currency transactions get a small grey box with a cross > >> (hinting the transaction is inconsistent). > >> > >> How do I best deal with this? > >> Is it possible to keep my old multi currency transactions as-is and > >> use trading accounts only for securities/stocks? > >> > >> If not, how do I migrate while ensuring my ten years worth of data > >> does not suddenly get inconsistent? > > > > You should be able to use the "Check & Repair" commands in the Actions > > menu to add the trading account splits to existing transactions. I > > would certainly save a copy of my data before doing this, and try it on > > a few transactions first. Your situation is complex enough that it is > > not unlikely that this won't do exactly what you want, but it's worth a > > try assuming you have good backup. > > Thank you, I think that worked indeed. > > I still need to cross-check everything (at the first glance things look > OK). > > So then I'd have a general question on the multi currency feature: > > 1.) Are "Trading Accounts" just an *alternative* way to handle multi > currencies (and as such have nothing to do with "trading")? > > 2.) Trading Account seem to be way more powerful than storing the > exchange rate in each transaction > > 3.) Why exactly aren't they enabled by default if they are so superior? > Why let people my default use the way that makes things less consistent > and error-prone? > > Thanks, > Lukas > > > > > ___ > 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.
Re: [GNC] Switching to trading accounts in existing database
Hi Mike, On 2021-01-21 02:24, Mike Alexander wrote: On 19 Jan 2021, at 20:08, Lukas Haase wrote: So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? You should be able to use the "Check & Repair" commands in the Actions menu to add the trading account splits to existing transactions. I would certainly save a copy of my data before doing this, and try it on a few transactions first. Your situation is complex enough that it is not unlikely that this won't do exactly what you want, but it's worth a try assuming you have good backup. Thank you, I think that worked indeed. I still need to cross-check everything (at the first glance things look OK). So then I'd have a general question on the multi currency feature: 1.) Are "Trading Accounts" just an *alternative* way to handle multi currencies (and as such have nothing to do with "trading")? 2.) Trading Account seem to be way more powerful than storing the exchange rate in each transaction 3.) Why exactly aren't they enabled by default if they are so superior? Why let people my default use the way that makes things less consistent and error-prone? Thanks, Lukas ___ 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] Switching to trading accounts in existing database
On 19 Jan 2021, at 20:08, Lukas Haase wrote: So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? You should be able to use the "Check & Repair" commands in the Actions menu to add the trading account splits to existing transactions. I would certainly save a copy of my data before doing this, and try it on a few transactions first. Your situation is complex enough that it is not unlikely that this won't do exactly what you want, but it's worth a try assuming you have good backup. Mike ___ 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] Switching to trading accounts in existing database
Hi, I have been using gnucash for over ten years. My data contains all data (Sqlite database ~20MB). I have lived in four different countries and since the move never was a clear cut, I ended up having four separate Equity/Assets/Liabilities/Expenses/Income hierarchies, one for each. I made extensive usage of the multi-currency functionality (e.g., living in country A, paying with credit card from country B) which has an exchange rate for each transaction/split when the two accounts have different currencies. Recently I stumbled into this problem: "Securities" (crypto currency) which I buy from different brokers in each country. So I have a broker in Canadian dollars, US Dollars, Euro. Now these "shares" (=Bitcoin) get transfered to my personal wallet. This personal wallet is represented as Stock account with security BTC and the sources of its transactions are the stock accounts of each trader with different currencies. Suddenly it gets messy ... the personal wallet account would mix different currencies in the same ledger (Price/Buy/Sell values represent 1:1 the values of the source accounts -- there is no currency conversion). So I got recommended using trading accounts. But suddenly all my previous multi-currency transactions get a small grey box with a cross (hinting the transaction is inconsistent). How do I best deal with this? Is it possible to keep my old multi currency transactions as-is and use trading accounts only for securities/stocks? If not, how do I migrate while ensuring my ten years worth of data does not suddenly get inconsistent? Thanks, Lukas ___ 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.
