[GNC] Feature Request: Add Support for Functional Currency Amount in Transactions

Sun Jan 5 12:19:50 EST 2025

Kevin,

Yes, IAS 21 comes up in the discussion on bug 797796. Making the transaction currency the book (functional) currency in all cases will do exactly what IAS 21 requires: The amount of each foreign currency split will be in the foreign currency, the value will be in the book currency, and the spot price will be the ratio between the two.

Note that you can get most of the way there by making sure to start all transactions in a book-currency register. If you use Split View to record the transaction the current register account doesn’t even need to be in any of the splits.

You seem to be too focussed on getting us to implement your specific workaround. We’re not likely to do that, 

Regards,
John Ralls

> On Jan 5, 2025, at 06:45, Tian Kevin <tian_kun at outlook.com> wrote:
> 
> Thank you for your response. I would like to provide additional context regarding the importance of supporting functional currency amounts in transactions.
> Compliance with Accounting Standards
> Financial accounting must adhere to established accounting standards such as IFRS, which require functional currency financial statements. At the end of each month, accountants need to calculate exchange gains or losses based on currency fluctuations. Without native support for functional currency amounts in GnuCash, this process becomes more labor-intensive and prone to errors.
> 《IAS 21 The Effects of Changes in Foreign Exchange Rates》
> 21 A foreign currency transaction shall be recorded, on initial recognition in the functional currency, by applying to the foreign currency amount the spot exchange rate between the functional currency and the foreign currency at the date of the transaction.
> 
> Comparison with Other Financial Software
> Several accounting software solutions, such as Manager.io <http://manager.io/> and NetSuite, natively support the functional currency amount for every foreign transaction. These systems allow users to explicitly input or calculate the exchange rate for each transaction, ensuring accurate reporting and compliance. Adding this functionality to GnuCash would enhance its competitiveness and usability for users managing multi-currency finances.
> Current Workaround Using Access Database
> Currently, I connect to GnuCash's backend database via Microsoft Access to add a functional currency column manually. I achieve this by creating queries and supplementing the necessary data for reporting. While this workaround meets my needs temporarily, it would be far more efficient and reliable to have this feature implemented natively within GnuCash.
> I strongly believe that incorporating functional currency support would benefit not only individual users but also businesses relying on GnuCash for multi-currency accounting. I am more than willing to assist with testing or provide additional examples of how this feature could be utilized.
> Thank you again for your time and consideration. I look forward to your feedback.
> Best regards,
> Kevin
> 发件人: John Ralls <jralls at ceridwen.us>
> 发送时间: 2025年1月5日 4:54
> 收件人: Derek Atkins <derek at ihtfp.com>
> 抄送: Tian Kevin <tian_kun at outlook.com>; gnucash-devel at gnucash.org <gnucash-devel at gnucash.org>; gnucash-user at gnucash.org <gnucash-user at gnucash.org>
> 主题: Re: [GNC] Feature Request: Add Support for Functional Currency Amount in Transactions
>  
> I’ve been mulling this for some time, incited by a user who calls himself CDB-Man in the bug tracker and IRC. CDB-Man is a licensed accountant in Vancouver, BC. There’s a lot of discussion in https://bugs.gnucash.org/show_bug.cgi?id=797796.
> 
> I don’t think we need to add anything, just make a small change to the way transaction currency is selected. It’s currently either the currency of the register in which the transaction is created or, if that register is denominated in a non-currency commodity, the currency of the nearest parent account that’s denominated in a currency. We could instead always use the book currency for the transaction currency. This would I think accomplish all of the goals Kevin lays out with one significant cost: It would complicate valuing securities that are normally priced in a currency other than the book currency. I think that could be addressed by adding a third pair of trading splits for the pricing currency.
> 
> Regards,
> John Ralls
> 
>> On Jan 4, 2025, at 19:25, Derek Atkins <derek at ihtfp.com> wrote:
>> 
>> Back around GnuCash 1.4 each split had a home currency / value.  It was removed in 1.6.  The argument at the time was that if you're holding a handful of, e.g. Mexican Pesos, it doesn't really matter what the USD value was when you acquired them, it only matters what the value is when you need to report it, or when you transact with it.
>> I didn't particularly buy the argument, but I didn't have a say at the time.
>> Still, there has not been a call to return to that method since it was removed over 20 years ago   so I will ask, are you sure you need the extra data? Can it not be computed through other means?
>> -derek
>> Sent using my mobile device. Please excuse any typos.
>> On January 4, 2025 19:27:58 Tian Kevin <tian_kun at outlook.com> wrote:
>> 
>>> Dear GnuCash Development Team,
>>> I hope this email finds you well. My name is Kevin as an accountant, and I am a GnuCash user who manages multi-currency financial transactions. I appreciate the powerful features GnuCash provides for personal and business finance management.
>>> I am writing to propose a feature enhancement for GnuCash: adding support for functional currency amounts in transactions. This feature would allow users to input and view amounts in their functional currency (e.g., a home or base currency) alongside the foreign currency used in the transaction. Additionally, it would ensure compliance with IFRS standards, which require the presentation of financial statements in the functional currency.
>>> ________________________________
>>> Use Case and Benefits
>>> 
>>> 1.  Simplified Reporting: Users could generate financial reports directly  in their functional currency without manually recalculating values for  foreign currency transactions.
>>> 2.  Improved Accuracy: By maintaining the functional currency amounts  within the database, exchange rate differences can be calculated more  accurately and transparently.
>>> 3.  Broader Adoption: Supporting functional currency aligns with  international accounting standards, making GnuCash more appealing to  professional users.
>>> 
>>> ________________________________
>>> Proposed Implementation
>>> 
>>> *   Database: Add a new column (e.g., functional_currency_amount) in the  splits table to store the converted amount.
>>> *   User Interface: Allow users to enter the functional currency amount  during transaction creation or let the system calculate it using exchange  rates.
>>> *   Reporting: Update built-in reports to include functional currency  amounts for financial analysis.
>>> 
>>> ________________________________
>>> I understand that this might be a significant development effort, but I believe it could greatly enhance GnuCash's capabilities. If needed, I would be happy to provide more detailed use cases or assist with testing this feature.
>>> Thank you for considering my request. I look forward to hearing your thoughts.
>>> Best regards,
>>> 
>>> 
>>> Kevin
>>> 
>>> 
>>> _______________________________________________
>>> gnucash-user mailing list
>>> gnucash-user at 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20250105/9c20908c/attachment.htm>