But you can’t then quotes for cross-currency values directly, because such
quotes will be expressed in terms of the primary unit - BTC, for example.
—
Peter West
p...@pbw.id.au
“But when you give to the needy, do not let your left hand know what your right
hand is doing, so that your giving may
Yes, quite right! This workaround is for an account involving only BTC txs.
Can still cross-currency by entering the rate manually, which should still be
less trouble, busywork and error-prone than treating Bitcoin as a stock.
Until Bitcoin is coded into GC as a proper currency and a possible un
On Sat, 18 Jun 2022 at 03:45, Michael or Penny Novack <
stepbystepf...@comcast.net> wrote:
>
>
> IF what you mean by "exclusively in bitcoin" is accounting JUST in
> bitcoin, you would not have to treat it as stock/commodity evaluated in
> some other currency. You could keep a set of books denomin
Good. That eliminates my concern. I hope Julie finds a solution.
On June 17, 2022 11:27:08 PM EDT, David H wrote:
>I've set up BTC and ETH as Digital cash as per Julie's screenshots (I
>think) and it seems to retrieve the quotes ok, see below...
>
>Cheers David H
>
>[image: image.png]
>
>On Sat,
On 6/18/2022 12:05 AM, HSC wrote:
Thank you, Michael D Novack!
That's a great solution until GNC development catches up to the crypto world:
we will keep separate GNC file for each cryptoasset.
The remaining problem is that Bitcoin Lightning goes to 11 decimal places, and
Ethereum I think goes
It might be intended behavior, but I noticed on posting a Bill while
having the Bills Due Reminder window open, the list of bills does not
update to reflect the newly posted bill.
It does however remove bills upon processing a payment (though per
https://bugs.gnucash.org/show_bug.cgi?id=797282
I'm pretty sure the issue isn't GnuCash development. (based on previous
threads) The issue is that BTC and other 'coins' don't have ISO currency
codes. When/if they get one, GC will include them.
Regards,
Adrien
On 6/17/22 11:05 PM, HSC wrote:
Thank you, Michael D Novack!
That's a great solu
On Sat, 18 Jun 2022 at 16:12, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> I'm pretty sure the issue isn't GnuCash development. (based on previous
> threads) The issue is that BTC and other 'coins' don't have ISO currency
> codes. When/if they get one, GC will include them.
>
> Reg
I have been populating my accounts with CSV. During the import, the tool
doesn't have any existing transactions to match, so most of them get assigned
the expense category 'Imbalance-USD'.
I am to the point of making sure that accounts are reconciled and transactions
don't have left over or bad
First, Imbalance-USD is not an expense account but a top level account, and
it is intended to be used only when an automated function is unable to form
a fully balanced transaction. You are correct that you can look under that
account name to find unbalanced transactions if and when they exist.
Y
I'm not arguing anything. I'm simply passing along what I've seen the
devs talk about in prior threads.
Of course, if they have time out of their day coding GnuCash to chime
in, I'm sure they can enlighten you more on the issues they have to
consider in the code, and why that decision was made
I agree that the matching step is critical when importing and the proper
account should be assigned during import. I also agree that the OP needs to
understand Double Entry accounting better, However, if he has "empty"
transactions in the imbalance account, my bet is that if he clicks on the s
Hello all,
Sorry it's been a while, but a pre-release release candidate of
Finance::Quote v1.52 is available from Github.
https://github.com/finance-quote/finance-quote/releases/tag/v1.52-rc.1
A Github discussion for this release can be found at
https://github.com/finance-quote/finance-quote
Gyle,
Whether you delete the imbalance account or not once it is empty is a user
preference. Some dislike seeing the imbalance account in their books, and
delete it if it is empty. Others (like myself and you) leave that account in
place. I leave it because it just reappears again later anyways
When I say entry, I refer to the entire transaction, but I get your point.
Sent from Samsung Galaxy smartphone.
Original message
From: "David T."
Date: 6/18/22 4:24 PM (GMT-05:00)
To: gnucash-user@gnucash.org, Gyle McCollam , David Carlson
, Kevin T
Cc: gnucash-user@gnuca
>
> Message: 7
> Date: Sat, 18 Jun 2022 09:43:13 -0400
> From: Michael or Penny Novack stepbystepf...@comcast.net
>
> To: gnucash-user@gnucash.org
> Subject: Re: [GNC] Bitcoin Lightning payments
> Message-ID: 55b50d3d-18ce-8176-01d1-39616d6b1...@comcast.net
>
> There is a (potential) solutio
On 6/18/2022 2:00 PM, Adrien Monteleone wrote:
I'm not arguing anything. I'm simply passing along what I've seen the
devs talk about in prior threads.
Of course, if they have time out of their day coding GnuCash to chime
in, I'm sure they can enlighten you more on the issues they have to
cons
The confusion arises when you use "entry" for both splits and transactions in
the same paragraph, as you did here.
On June 18, 2022 4:57:57 PM EDT, Gyle McCollam wrote:
>When I say entry, I refer to the entire transaction, but I get your point.
>
>
>
>Sent from Samsung Galaxy smartphone.
>
>
>
Hello. I would like to plan out future replacement of many physical
assets. I am thinking of tracking them as commodities and importing future
transactions, then separately importing estimated future pricing. I notice
when I post an entry with a number of shares but no price, the price
database
19 matches
Mail list logo
