Uh let's for the moment forget the multiple currencies.
Rather than that, let's examine basic accounting as applied to "sales"
<>
You would have an account of type assets for inventory << might or might
not have sub accounts for individual items in a case like yours,
particularly, as I
Well, I think it is entirely correct... if I sell stocks at a loss, the
"capital gain" account decreases because I've actually had a loss.
If you created an expense account, I think GunCash will show expenses as
positive (it may be an option).
But I don't have any problem with having a negative n
On Mon, Jun 16, 2025 at 2:51 PM Boniforti Flavio
wrote:
> This all looks correct: the "shipping cost of sales" SHOULD wind up bing 0
>> because you didn't actually have any expense (they actually paid for it,
>> not you). That account should show an increase when you purchased the
>> shipping lab
>
> This all looks correct: the "shipping cost of sales" SHOULD wind up bing 0
> because you didn't actually have any expense (they actually paid for it,
> not you). That account should show an increase when you purchased the
> shipping label, and then decreased back down to zero when you received
Hi Richard and thanks for replying.
I do already have a "Income:Music Equipment Sales CHF" account, but perhaps
I don't think it's correct to add a "decrease" in that account of CHF 32.-
(which is the loss I suffered). Probably it's a matter of perspective... I
could create a separate "Expenses:Mus
On Mon, Jun 16, 2025 at 6:00 AM Boniforti Flavio
wrote:
> Hi all.
> I thought I got this one sorted last year, but apparently my notes are not
> correct/up-to-date... please bear with me.
>
> The SECOND USE CASE is (to me) a bit more complex:
> - item POD, sub-account of the "EUR instrument colle
On Mon, Jun 16, 2025 at 6:00 AM Boniforti Flavio
wrote:
> Hi all.
>
> I've got a collection of (vintage) music instruments - I have an account
> for each item, where I put the money I've spent to buy such items. Each
> item is a sub-account of a super-account "Instrument collection" - and I
> got
Tried that and tried last before date. Both had same results. Only PHP
rates are in the price database and the entry for 7/5/23 is correct.
Stephen M Butler
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint: 8A25 9726 D439 7
A guess on my part.
In the Balance sheet:
Click on Options
Click on Commodities
Click on Price Source
Try Closet to Report Date
You might also check if the conversion rate between PHP and USD was
recorded:
Tools
Price Database
Currencies
Look in both USD
Hello, Norbert:
On 2022-07-20 03:41, Norbert Klein wrote:
Servus GNUcash helper,
thanks for the detailed advice - I am working through it.
But I get aware that my problems start sometime one more level down,
when I read: "When you create a new account, you have the option to
define the commodi
Thanks, David,
This kind of VERY simple example is really helpful for a beginner:
Expenses
- Groceries
- - USD (USD-denominated account)
- - KHR (KHR-denominated account)
Norbert
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your s
Servus GNUcash helper,
thanks for the detailed advice - I am working through it.
But I get aware that my problems start sometime one more level down,
when I read: "When you create a new account, you have the option to
define the commodity in which that account is denominated."
Yes, I try to cre
Thanks, Paul (yours was the first), and several others who responded.
My responses are often late, because my Internet access (in the
countryside in Cambodia) is not regular and stable.
Thanks a lot!
Norbert
___
gnucash-user mailing list
gnucash-use
Norbert,
Further to Paul's comments: managing multiple currency accounts can be
confusing at first, but it begins to make sense after a while. If your need to
track funds in the alternate currency is limited to occasional transactions
(for example, you go on vacation and take out a chunk of mon
Servus Norbert, welcome to GnuCash:
On 2022-07-16 22:14, Norbert Klein wrote:
I am a new gnucash user, living in Cambodia (since 32 years).
I downloaded (in Windows 10), installed and tried to set up gnucash with
the US$ as the basic currency (which was already set-up as a default). I
have not
Each account in your CoA operates in a specific currency, which is specified
when you create it. I expect you haven't seen this yet, as you haven't set
up your accounts. I'm pretty sure you don't need to add anything new for the
Riel (KHR), as all the standard currencies are already built in. In fa
On 7/3/2022 12:55 AM, Adrien Monteleone wrote:
Michael, I gave a quite generic caveat if you didn't notice, but
thanks for the specific exception for posterity! (for that 1%, or so,
as I guess various of us from time to time, might judge or measure
that statistic, or make it up, as the case my
Michael, I gave a quite generic caveat if you didn't notice, but thanks
for the specific exception for posterity! (for that 1%, or so, as I
guess various of us from time to time, might judge or measure that
statistic, or make it up, as the case my be, or warrant.)
Regards,
Adrien
On 7/2/22 12
On 7/2/2022 3:38 AM, Adrien Monteleone wrote:
Starting from the source account is good practice no matter the type
of transaction.
Since funds in double-entry have to 'come from somewhere' and 'go to
somewhere', by always entering the transaction in the source account,
you are always choosing
> Date: Sat, 2 Jul 2022 02:38:11 -0500
> From: Adrien Monteleone adrien.montele...@lusfiber.net
>
> To: gnucash-u...@lists.gnucash.org
> Subject: Re: [GNC] Multiple currencies in split tx
> Message-ID: t9osl3$j5e$1...@ciao.gmane.io
>
> Content-Type: text/plain; char
Starting from the source account is good practice no matter the type of
transaction.
Since funds in double-entry have to 'come from somewhere' and 'go to
somewhere', by always entering the transaction in the source account,
you are always choosing the destination(s).
Life is much less confus
> --
>
> Message: 4
> Date: Thu, 30 Jun 2022 15:03:37 -0700
> From: list+gnuc...@jdlh.com
> To: gnucash-user@gnucash.org
> Subject: Re: [GNC] Multiple currencies in split tx
> Message-ID: 2b04aeb5-7f10-cfa9-3960-261bbee4b...@jdlh.com
>
Hello, HSC:
Welcome to GnuCash.
On 2022-06-30 13:30, HSC wrote:
...Is it possible to account in one GC split entry for a tx in which a payment
processor simultaneously makes a payment to two different vendors in two
different local currencies?...
In my experience, yes. I have made some tran
Hi Mike,
> It seems to me that the simplest solution, and one that might work reasonably
> well, is to make it possible (via a view option) to switch any register into
> the format used for non-currency registers where there are separate columns
> for shares, price, and value for each split.
On 20 August 2019 at 13:17, Jeff Abrahamson said:
> When I said price editor, I meant the price database. I've been
> assuming that the rates there are used for proposing rates on new
> transactions.
They are, but mainly because there has to be *some* default value. In
most cases you will want
I have been following this discussion rather closely. I am American (not
something to be proud of right now), but I do travel a lot on business
worldwide, dealing with a lot of currencies. It'll be interesting to see
how this resolves.
On Tue, Aug 20, 2019 at 4:21 AM Jeff Abrahamson wrote:
> W
When I said price editor, I meant the price database. I've been
assuming that the rates there are used for proposing rates on new
transactions.
Anyway, it sort of goes to my point that I think the documentation is
less than clear for those of us who have regular transactions in
multiple currencie
I thought this thread was discussing only transactions, not reports. Jeff,
the Price Editor does not come in to play in individual transactions.
Transactions are self-contained with whatever exchange rates happen therein.
The Price editor exists for reports that are not tied to individual
transac
It's not entirely unuseful that some of the discussion happens here on
the user list. User input may be of interest.
I'll add only one point, which is that I think the current English
language documentation doesn't explain as well as it might how to use
gnucash in the presence of more than one cu
I’ve been thinking for a while about how the register could be changed to
better handle multiple currency transactions with trading accounts turned on.
Back when I implemented trading accounts I knew this was a problem. However
at that time it was expected that the Register2 rewrite of the r
On second thought, a slight correction —if each account only showed amounts
converted to its own currency - NONE of the splits would match any other
account’s view of the transaction.
The Credit of GBP from Transferwise would be a different amount in the
Transferwise_CHF account and a 3rd amoun
> On Aug 16, 2019, at 11:39 AM, Jeff Abrahamson wrote:
>
>
> 2. I've been taught in accounting that transactions must balance, and
> so I was expecting to see the GBP register all in GBP, the CHF register
> all in CHF, and the EUR register all in EUR. That is, if one sums the
> columns of a re
It's a difference in the way that the register works with or without trading
accounts. If trading accounts are turned off then the register displays all
splits converted to that register account's currency. If they're on then it
displays each split in its own account's currency, with symbols for
Thanks, that's great, I'll have a play with that after work.
Two points concern me:
1. I don't see currency symbols in my registers. Is this a setting?
2. I've been taught in accounting that transactions must balance, and
so I was expecting to see the GBP register all in GBP, the CHF register
Sorry, I thought I proofed that better. Wherever you see €5.13, that should be
€5.12. It really doesn’t matter, as it is just for illustration.
Regards,
Adrien
> On Aug 16, 2019, at 11:13 AM, Adrien Monteleone
> wrote:
>
>
> The EUR 5.13 price is based on today’s rate between EUR-GBP above a
So the Cafe’s price was CHF 5.70?
Your card was debited GBP 4.67?
The Expense:Coffee account is set to EUR?
First, yes, you’ll need Trading Accounts turned on.
Second, open the price db and fetch rates, then check the EUR-GBP rate, you’ll
need it later. (I don’t see a way around this at presen
Jeff Abrahamson writes:
> Apparently the mailing list strips images, even very tiny ones.
The mailing list strips HTML.
If you attach an image then it'll make it through.
> The first image simply showed Transferwise associating 5.70 CFH = 4.67 GBP.
>
> The second showed that gnucash is creatin
The list server doesn't like inline images. It mostly works with images stuck
at the end of the message. Mostly.
In what account is the 2.80 debit? In which account (and so which currency) did
you create the transaction?
A side note, have you considered/tried enabling trading accounts? Some use
On 15/08/2019 18:55, John Ralls wrote:
>> On Aug 15, 2019, at 7:38 AM, Jeff Abrahamson wrote:
>>
>> Somewhat related, I thought to import historical currencies, as I'm back
>> filling some data for analysis purposes. I grabbed 10 years of daily
>> quotes and imported them (3600 or so rows of data
> On Aug 15, 2019, at 7:38 AM, Jeff Abrahamson wrote:
>
> Somewhat related, I thought to import historical currencies, as I'm back
> filling some data for analysis purposes. I grabbed 10 years of daily
> quotes and imported them (3600 or so rows of data per currency). All ok
> for GBP - EUR.
Apparently the mailing list strips images, even very tiny ones.
The first image simply showed Transferwise associating 5.70 CFH = 4.67 GBP.
The second showed that gnucash is creating a correcting split in the
transaction I'd entered:
512452_Transferwise CHF 5.70
6212_cafe
Am 07.11.2018 um 01:32 schrieb Matthew Pounsett:
> On Tue, 6 Nov 2018 at 15:30, Christian Kluge wrote:
>
>>> The currency logic is pretty simple: every amount you see in the invoice
>>> entries is assumed to be in the customer's default currency. They income
>>> account for each entry can be in a
On Tue, 6 Nov 2018 at 15:30, Christian Kluge wrote:
> > The currency logic is pretty simple: every amount you see in the invoice
> > entries is assumed to be in the customer's default currency. They income
> > account for each entry can be in a currency different from the invoice
> > account. In
On Tue, 6 Nov 2018 at 12:22, Geert Janssens
wrote:
> I believe you have just pushed the boundaries of what to do with invoices
> further than anyone ever could have imagined :)
>
Good? :)
>
> I don't think anyone so far ever considered the case of having billable
> expenses in a different curr
Hi,
just a minor addition.
Am 06.11.2018 um 21:29 schrieb Christian Kluge:
> Hi,
>
> Am 06.11.2018 um 18:22 schrieb Geert Janssens:
>> Op dinsdag 6 november 2018 17:16:16 CET schreef Matthew Pounsett:
>>> I have cases with both billable employee expenses (vouchers) and billable
>>> purchases (ve
Hi,
Am 06.11.2018 um 18:22 schrieb Geert Janssens:
> Op dinsdag 6 november 2018 17:16:16 CET schreef Matthew Pounsett:
>> I have cases with both billable employee expenses (vouchers) and billable
>> purchases (vendor bills) which need to go on customer invoices. This is
>> fairly straight forwar
Op dinsdag 6 november 2018 17:16:16 CET schreef Matthew Pounsett:
> I have cases with both billable employee expenses (vouchers) and billable
> purchases (vendor bills) which need to go on customer invoices. This is
> fairly straight forward... the problem I'm having is how to deal with these
> w
47 matches
Mail list logo
