[GNC] Forecasting with Commodity Future Prices

[Samantha Ahuja]

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 will have a new price on that date of $0.  If I delete that price
from the price database, it will then revert to using the last imported
price, which is what I want.

Is there a way to default to it using the imported price list such that it
will not create $0 prices in the price database?  I hope this is making
sense.  Thanks for any insight anyone can provide.
___
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] rookie question Imbalance-USD

[David T. via gnucash-user]

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.
>
>
>
> 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@gnucash.org
>Subject: Re: [GNC] rookie question Imbalance-USD
>
>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 you miss 
>an entry.
>
>Also, I'll note that you made a misleading statement late in the first 
>paragraph when you said that "If he deletes the entry, he will delete it from 
>the other accounts as well." In this instance, I think you meant to say "If he 
>deletes the **transaction,** he will delete it from the other accounts as 
>well." It's a minor, yet significant, difference in terminology. An entry (as 
>I understand) is the single line within a transaction, synonymous with the 
>Gnucash term "split." The Transaction is made up of two or more splits/entries.
>
>Best,
>David T.
>
>On June 18, 2022 2:57:01 PM EDT, Gyle McCollam  wrote:
>
>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 
>split icon in the toolbar, he will see his debit and credit accounts, plus the 
>empty imbalance account.  When correcting the imbalance entry, he needs to 
>open the split and click on the imbalance entry and change that to the proper 
>account.  I think he added the proper account, entered the amount, then 
>removed the amount from the imbalance account. Doing it this way you can't 
>delete the imbalance account, unless you "jump" to one of the other accounts 
>and delete it from there.  If he deletes the entry, he will delete it from the 
>other accounts as well, which he doesn't want to do.
>  You state that "Once all funds are re-allocated there should be no entries 
> remaining and you can safely delete that account."  You don't delete the 
> account, once there are no entries the account it is irrelevant and if you 
> have it set to not display unused accounts you won't see it unless in the 
> future there is another entry in there,
>
>
>Thank You,
>Gyle McCollam
>
>Gyle McCollam
>
>609.680.2326 Mobile
>
>gmccol...@live.com   email
>
>From: gnucash-user  on 
>behalf of David Carlson 
>Sent: Saturday, June 18, 2022 1:59 PM
>To: Kevin T 
>Cc: gnucash-user@gnucash.org 
>Subject: Re: [GNC] rookie question Imbalance-USD
>
>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.
>
>You might find it useful to re-read about double entry bookkeeping in the
>various help resources.  The F1 key should work while in GnuCash.
>
>We never use the term "Category" to refer to anything in GnuCash, not even
>"Expense" Accounts.
>
>The fact that you are finding "empty" transactions there indicates that you
>are not always deleting references to that account after re-allocating
>funds to the desired account.  Once all funds are re-allocated there should
>be no entries remaining and you can safely delete that account.  It will be
>re-created if new transactions appear.
>
>As you noticed, double-clicking is nearly useless in GnuCash.  It does work
>to change the sort order of columns in some windows.
>
>When using an import function, GnuCash is trying to learn what Account
>transactions have been applied to in the past so it can try to use the same
>account with similar transactions.  That is why it is important to use the
>"Matching" step to correct account assignments before the import process is
>closed.
>
>Lastly, text files in Windows OS always use CR-LF, but other OS's mostly
>use CR.  This creates confusion when viewing text files in other OS's.
>
>
>On Sat, Jun 18, 2022 at 11:54 AM Kevin T via gnucash-user <
>gnucash-user@gnucash.org> wrote:
>
> 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
> 

Re: [GNC] Bitcoin Lightning payments

[Michael or Penny Novack]

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 
consider in the code, and why that decision was made. As far as I'm 
aware, they aren't specifically 'anti-crypto'.


Perhaps if one of them (or an experienced user) has the time, they can 
put something in the FAQ on the subject. (it is a fairly frequent 
topic here on the list.)


Of course, if you took the time to search the list archives, you'll 
find those discussions and explanations. 


I'll reply not a a developer but as somebody whose done LOTS of software 
design in my day.


a) If the developers did the job right, the ISO currency codes are not 
hard coded but in "app data" read in when the program starts << that 
means they can be changed without changing the code in any program, just 
data in a file.


b) NO, not a "lame excuse". Misunderstanding of what the ISO is/does. It 
sets STANDARDS. In other words, "for currency X use ABX" (or whatever). 
Dr. David, if there is no agreed standard for what the three letter 
currency code for "bitcoin" is, what should the developers use? Should 
they simply use ANY three characters not already in use for some 
currency that has an ISO currency code? There are > 17 thousand three 
character codes possible and only the order of a hundred or two in use. 
Whatever they pick the odds are worse then 10,000:1 it won't agree with 
the code chosen by any other team of software developers OR with what 
eventually become the standardized currency code for bitcoin if/when the 
ISO chooses one.


   Your beef should not be with the gnucash developers but with the 
ISO. You bitcoin users need to lobby THEM to choose a code for bitcoin. 
Actually, there are TWO standards you need them to choose. One one is 
the two character prefix to be used when a currency that is not the 
currency of a nation state (or union of states, like EU in EUR). Then 
the third character that means "bitcoin".


   Actually, there ARE several codes (competing codes) in use for 
Bitcoin. Any of those might end up as the eventual code except BTC 
(which violates ISO 4217 because BT is the code for an existing nation 
state). When I was suggesting that a two character code first, note that 
"CC" (for "cryptocurrency" will not do as "CC" already assigned as a 
"country code".


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
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] Bitcoin Lightning payments

[HSC]

> 

> 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) solution for that. Probably not workable for
> ridiculously high number of decimal points* you described. But let's say
> you needed something smaller than that range.
> 

> It is called "scaling". You have probably seen examples of this if you
> have looked at the annual report of organizations where the totals are
> in the tens or hundreds of millions. Instead of being in whole dollars,
> the report might be in units of a thousand dollars. It also works the
> other way around.
> 

> Thus if you needed to express quantities of the order of $0.1
> (hundredths of a mil) but only had two decimal points available you
> could scale to the mil instead of the dollar << in other words "1" would
> stand for one mil, not one dollar >> If your problem is NOW the range of
> 

> values being too large to fit in the fields, I'll refer you to the
> reasoning below.
> 

> Michael D Novack
> 

> * PHYSICAL reality is constrained by relative number of decimal points
> to a relatively small number, say at most, six or seven. I am talking
> here about when "adding things". In other words, when talking about real
> things, 1,000,000 and 1,000,001 are essentially equal. If you were
> counting two heaps separately, how certain would you be that they were
> actually unequal (or would an error in counting be more likely). We
> don't use counting, addition, subtraction, etc. to make a decision like
> that (though we could use "pairing"). In similar fashion, given two
> pieces of glass, one on top of the other, could measure how much farther
> apart in the middle than at the edges in wavelengths of light used to
> make the observation, or by how much the curvature of the surface
> departed from some conic section, but not in terms of the thickness of
> the pieces of glass.
> 


Thanks! I suppose we could have 2 Bitcoin books - one for txs over 1 BTC and 
one for txs under 1 BTC, expressed in sats.

We are interested in accounting both sides of the Bitcoin range, because we are 
testing BTCPayServer, which is a FOSS Bitcoin e-commerce  suite. It includes a 
Lightning node for accepting small, instant Bitcoin payments.
When it's running, in addition to its e-commerce txs, it is also constantly 
routing peer to peer Lightning Network BTC payments and making  small gains of 
a few sats or some hundreds of milisats for each such routing. Naturally, they 
can add up to significant amounts eventually.

The server interface provides  csv files to keep track of such income, which 
would be useful to track in GC as Lightning Network use increases.
I suppose we should test how the GC Import Assistant fares with such inputs.

HSC

signature.asc
Description: OpenPGP digital signature
___
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] rookie question Imbalance-USD

[Gyle McCollam]

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@gnucash.org
Subject: Re: [GNC] rookie question Imbalance-USD

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 you miss 
an entry.

Also, I'll note that you made a misleading statement late in the first 
paragraph when you said that "If he deletes the entry, he will delete it from 
the other accounts as well." In this instance, I think you meant to say "If he 
deletes the **transaction,** he will delete it from the other accounts as 
well." It's a minor, yet significant, difference in terminology. An entry (as I 
understand) is the single line within a transaction, synonymous with the 
Gnucash term "split." The Transaction is made up of two or more splits/entries.

Best,
David T.

On June 18, 2022 2:57:01 PM EDT, Gyle McCollam  wrote:

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 split 
icon in the toolbar, he will see his debit and credit accounts, plus the empty 
imbalance account.  When correcting the imbalance entry, he needs to open the 
split and click on the imbalance entry and change that to the proper account.  
I think he added the proper account, entered the amount, then removed the 
amount from the imbalance account. Doing it this way you can't delete the 
imbalance account, unless you "jump" to one of the other accounts and delete it 
from there.  If he deletes the entry, he will delete it from the other accounts 
as well, which he doesn't want to do.
  You state that "Once all funds are re-allocated there should be no entries 
remaining and you can safely delete that account."  You don't delete the 
account, once there are no entries the account it is irrelevant and if you have 
it set to not display unused accounts you won't see it unless in the future 
there is another entry in there,


Thank You,
Gyle McCollam

Gyle McCollam

609.680.2326 Mobile

gmccol...@live.com   email

From: gnucash-user  on 
behalf of David Carlson 
Sent: Saturday, June 18, 2022 1:59 PM
To: Kevin T 
Cc: gnucash-user@gnucash.org 
Subject: Re: [GNC] rookie question Imbalance-USD

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.

You might find it useful to re-read about double entry bookkeeping in the
various help resources.  The F1 key should work while in GnuCash.

We never use the term "Category" to refer to anything in GnuCash, not even
"Expense" Accounts.

The fact that you are finding "empty" transactions there indicates that you
are not always deleting references to that account after re-allocating
funds to the desired account.  Once all funds are re-allocated there should
be no entries remaining and you can safely delete that account.  It will be
re-created if new transactions appear.

As you noticed, double-clicking is nearly useless in GnuCash.  It does work
to change the sort order of columns in some windows.

When using an import function, GnuCash is trying to learn what Account
transactions have been applied to in the past so it can try to use the same
account with similar transactions.  That is why it is important to use the
"Matching" step to correct account assignments before the import process is
closed.

Lastly, text files in Windows OS always use CR-LF, but other OS's mostly
use CR.  This creates confusion when viewing text files in other OS's.


On Sat, Jun 18, 2022 at 11:54 AM Kevin T via gnucash-user <
gnucash-user@gnucash.org> wrote:

 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 account assignments.  Since
 Imbalance is one of those expense categories I thought that would be a good
 place to make sure things are clean.
 I double click that expense category and the tab populates.Most of these
 entries have no value in 

Re: [GNC] rookie question Imbalance-USD

[David T. via gnucash-user]

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 you miss 
an entry. 

Also, I'll note that you made a misleading statement late in the first 
paragraph when you said that "If he deletes the entry, he will delete it from 
the other accounts as well." In this instance, I think you meant to say "If he 
deletes the **transaction,** he will delete it from the other accounts as 
well." It's a minor, yet significant, difference in terminology. An entry (as I 
understand) is the single line within a transaction, synonymous with the 
Gnucash term "split." The Transaction is made up of two or more splits/entries. 

Best, 
David T.

On June 18, 2022 2:57:01 PM EDT, Gyle McCollam  wrote:
>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 
>split icon in the toolbar, he will see his debit and credit accounts, plus the 
>empty imbalance account.  When correcting the imbalance entry, he needs to 
>open the split and click on the imbalance entry and change that to the proper 
>account.  I think he added the proper account, entered the amount, then 
>removed the amount from the imbalance account. Doing it this way you can't 
>delete the imbalance account, unless you "jump" to one of the other accounts 
>and delete it from there.  If he deletes the entry, he will delete it from the 
>other accounts as well, which he doesn't want to do.
>  You state that "Once all funds are re-allocated there should be no entries 
> remaining and you can safely delete that account."  You don't delete the 
> account, once there are no entries the account it is irrelevant and if you 
> have it set to not display unused accounts you won't see it unless in the 
> future there is another entry in there,
>
>
>Thank You,
>Gyle McCollam
>
>Gyle McCollam
>
>609.680.2326 Mobile
>
>gmccol...@live.com   email
>
>
>From: gnucash-user  on 
>behalf of David Carlson 
>Sent: Saturday, June 18, 2022 1:59 PM
>To: Kevin T 
>Cc: gnucash-user@gnucash.org 
>Subject: Re: [GNC] rookie question Imbalance-USD
>
>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.
>
>You might find it useful to re-read about double entry bookkeeping in the
>various help resources.  The F1 key should work while in GnuCash.
>
>We never use the term "Category" to refer to anything in GnuCash, not even
>"Expense" Accounts.
>
>The fact that you are finding "empty" transactions there indicates that you
>are not always deleting references to that account after re-allocating
>funds to the desired account.  Once all funds are re-allocated there should
>be no entries remaining and you can safely delete that account.  It will be
>re-created if new transactions appear.
>
>As you noticed, double-clicking is nearly useless in GnuCash.  It does work
>to change the sort order of columns in some windows.
>
>When using an import function, GnuCash is trying to learn what Account
>transactions have been applied to in the past so it can try to use the same
>account with similar transactions.  That is why it is important to use the
>"Matching" step to correct account assignments before the import process is
>closed.
>
>Lastly, text files in Windows OS always use CR-LF, but other OS's mostly
>use CR.  This creates confusion when viewing text files in other OS's.
>
>
>On Sat, Jun 18, 2022 at 11:54 AM Kevin T via gnucash-user <
>gnucash-user@gnucash.org> wrote:
>
>> 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 account assignments.  Since
>> Imbalance is one of those expense categories I thought that would be a good
>> place to make sure things are clean.
>> I double click that expense category and the tab populates.Most of these
>> entries have no value in either the deposit or withdrawal columns.Some
>> do.Some even have a transfer account defined and values.
>> Sooo..  the stupid questions..
>> If they have a transfer account and values already specified, why is this
>> transaction in this expense category?How do I 

[GNC] Finance::Quote v1.52 Release Candidate 1 Available

[Bruce Schuck]

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/discussions/212.


Thank you.

- Bruce S and the rest of the F::Q team.
___
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] rookie question Imbalance-USD

[Gyle McCollam]

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 split 
icon in the toolbar, he will see his debit and credit accounts, plus the empty 
imbalance account.  When correcting the imbalance entry, he needs to open the 
split and click on the imbalance entry and change that to the proper account.  
I think he added the proper account, entered the amount, then removed the 
amount from the imbalance account. Doing it this way you can't delete the 
imbalance account, unless you "jump" to one of the other accounts and delete it 
from there.  If he deletes the entry, he will delete it from the other accounts 
as well, which he doesn't want to do.
  You state that "Once all funds are re-allocated there should be no entries 
remaining and you can safely delete that account."  You don't delete the 
account, once there are no entries the account it is irrelevant and if you have 
it set to not display unused accounts you won't see it unless in the future 
there is another entry in there,


Thank You,
Gyle McCollam

Gyle McCollam

609.680.2326 Mobile

gmccol...@live.com   email


From: gnucash-user  on 
behalf of David Carlson 
Sent: Saturday, June 18, 2022 1:59 PM
To: Kevin T 
Cc: gnucash-user@gnucash.org 
Subject: Re: [GNC] rookie question Imbalance-USD

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.

You might find it useful to re-read about double entry bookkeeping in the
various help resources.  The F1 key should work while in GnuCash.

We never use the term "Category" to refer to anything in GnuCash, not even
"Expense" Accounts.

The fact that you are finding "empty" transactions there indicates that you
are not always deleting references to that account after re-allocating
funds to the desired account.  Once all funds are re-allocated there should
be no entries remaining and you can safely delete that account.  It will be
re-created if new transactions appear.

As you noticed, double-clicking is nearly useless in GnuCash.  It does work
to change the sort order of columns in some windows.

When using an import function, GnuCash is trying to learn what Account
transactions have been applied to in the past so it can try to use the same
account with similar transactions.  That is why it is important to use the
"Matching" step to correct account assignments before the import process is
closed.

Lastly, text files in Windows OS always use CR-LF, but other OS's mostly
use CR.  This creates confusion when viewing text files in other OS's.


On Sat, Jun 18, 2022 at 11:54 AM Kevin T via gnucash-user <
gnucash-user@gnucash.org> wrote:

> 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 account assignments.  Since
> Imbalance is one of those expense categories I thought that would be a good
> place to make sure things are clean.
> I double click that expense category and the tab populates.Most of these
> entries have no value in either the deposit or withdrawal columns.Some
> do.Some even have a transfer account defined and values.
> Sooo..  the stupid questions..
> If they have a transfer account and values already specified, why is this
> transaction in this expense category?How do I find out from which account
> these transactions were originally created?  double clicking does
> nothing.If they contain no values, is it safe to delete them?
> I did import a number of times, trying figuring out the import behavior,
> into temp or no longer existing accounts.  Are these left over after
> deleting these accounts?
> version 4.1 windows.
> I have noticed that my original emails contain a ? for every CRLF that
> occurs, when the mailing list distributes this.  I am using yahoo mail to
> send this.   Is there a way to stop this ? mark 'feature'??
>
> Kevin
> ___
> 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 

Re: [GNC] Bitcoin Lightning payments

[Adrien Monteleone]

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. As far as I'm 
aware, they aren't specifically 'anti-crypto'.


Perhaps if one of them (or an experienced user) has the time, they can 
put something in the FAQ on the subject. (it is a fairly frequent topic 
here on the list.)


Of course, if you took the time to search the list archives, you'll find 
those discussions and explanations.


Regards,
Adrien

On 6/18/22 10:38 AM, Dr. David Kirkby wrote:

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.

Regards,
Adrien



That seems a *very* lame argument to me.

Dave.


___
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] rookie question Imbalance-USD

[David Carlson]

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.

You might find it useful to re-read about double entry bookkeeping in the
various help resources.  The F1 key should work while in GnuCash.

We never use the term "Category" to refer to anything in GnuCash, not even
"Expense" Accounts.

The fact that you are finding "empty" transactions there indicates that you
are not always deleting references to that account after re-allocating
funds to the desired account.  Once all funds are re-allocated there should
be no entries remaining and you can safely delete that account.  It will be
re-created if new transactions appear.

As you noticed, double-clicking is nearly useless in GnuCash.  It does work
to change the sort order of columns in some windows.

When using an import function, GnuCash is trying to learn what Account
transactions have been applied to in the past so it can try to use the same
account with similar transactions.  That is why it is important to use the
"Matching" step to correct account assignments before the import process is
closed.

Lastly, text files in Windows OS always use CR-LF, but other OS's mostly
use CR.  This creates confusion when viewing text files in other OS's.


On Sat, Jun 18, 2022 at 11:54 AM Kevin T via gnucash-user <
gnucash-user@gnucash.org> wrote:

> 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 account assignments.  Since
> Imbalance is one of those expense categories I thought that would be a good
> place to make sure things are clean.
> I double click that expense category and the tab populates.Most of these
> entries have no value in either the deposit or withdrawal columns.Some
> do.Some even have a transfer account defined and values.
> Sooo..  the stupid questions..
> If they have a transfer account and values already specified, why is this
> transaction in this expense category?How do I find out from which account
> these transactions were originally created?  double clicking does
> nothing.If they contain no values, is it safe to delete them?
> I did import a number of times, trying figuring out the import behavior,
> into temp or no longer existing accounts.  Are these left over after
> deleting these accounts?
> version 4.1 windows.
> I have noticed that my original emails contain a ? for every CRLF that
> occurs, when the mailing list distributes this.  I am using yahoo mail to
> send this.   Is there a way to stop this ? mark 'feature'??
>
> Kevin
> ___
> 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.
>


-- 
David Carlson
___
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] rookie question Imbalance-USD

[Kevin T via gnucash-user]

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 account assignments.  Since Imbalance is one of 
those expense categories I thought that would be a good place to make sure 
things are clean.
I double click that expense category and the tab populates.Most of these 
entries have no value in either the deposit or withdrawal columns.Some do.Some 
even have a transfer account defined and values.
Sooo..  the stupid questions..
If they have a transfer account and values already specified, why is this 
transaction in this expense category?How do I find out from which account these 
transactions were originally created?  double clicking does nothing.If they 
contain no values, is it safe to delete them?
I did import a number of times, trying figuring out the import behavior, into 
temp or no longer existing accounts.  Are these left over after deleting these 
accounts?
version 4.1 windows.
I have noticed that my original emails contain a ? for every CRLF that occurs, 
when the mailing list distributes this.  I am using yahoo mail to send this.   
Is there a way to stop this ? mark 'feature'??

Kevin
___
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] Bitcoin Lightning payments

[Dr. David Kirkby]

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.
>
> Regards,
> Adrien


That seems a *very* lame argument to me.

Dave.
-- 
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkir...@kirkbymicrowave.co.uk
https://www.kirkbymicrowave.co.uk/
Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom
___
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] Bitcoin Lightning payments

[Adrien Monteleone]

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 solution until GNC development catches up to the crypto world: 
we will keep separate GNC file for each cryptoasset.


___
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] Possible Bug - Due Reminder WIndow Not Updating on Posting

[Adrien Monteleone]

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, does not update the 
document count) and it will update existing bill info on editing. (such 
as due date and amount)


This is using v4.10 on BigSur.

If it is supposed to be updating, I'll go ahead and file a bug.

*This particular bill was created by duplicating a previous bill. 
(already paid) I'm not sure if this is relevant info or not. I'll see 
about testing with a bill created from scratch.


--
Regards,
Adrien

___
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] Bitcoin Lightning payments

[Michael or Penny Novack]

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 to 16.
Will round up to 1 sat for now, since it's still of insignificant value, but 
eventually that will also need some improvement.

There is a (potential) solution for that. Probably not workable for 
ridiculously high number of decimal points* you described. But let's say 
you needed something smaller than that range.


It is called "scaling". You have probably seen examples of this if you 
have looked at the annual report of organizations where the totals are 
in the tens or hundreds of millions. Instead of being in whole dollars, 
the report might be in units of a thousand dollars. It also works the 
other way around.


Thus if you needed to express quantities of the order of $0.1 
(hundredths of a mil) but only had two decimal points available you 
could scale to the mil instead of the dollar << in other words "1" would 
stand for one mil, not one dollar >> If your problem is NOW the range of 
values being too large to fit in the fields, I'll refer you to the 
reasoning below.


Michael D Novack

* PHYSICAL reality is constrained by relative number of decimal points 
to a relatively small number, say at most, six or seven. I am talking 
here about when "adding things". In other words, when talking about real 
things, 1,000,000 and 1,000,001 are essentially equal. If you were 
counting two heaps separately, how certain would you be that they were 
actually unequal (or would an error in counting be more likely). We 
don't use counting, addition, subtraction, etc. to make a decision like 
that (though we could use "pairing"). In similar fashion, given two 
pieces of glass, one on top of the other, could measure how much farther 
apart in the middle than at the edges in wavelengths of light used to 
make the observation, or by how much the curvature of the surface 
departed from some conic section, but not in terms of the thickness of 
the pieces of glass.


PS --- Not the place to discuss what "money" is, but it isn't, even in 
the case of "fiat currencies" something that is determined by fiat. 
That's why governments, etc. cannot control inflation/contraction by 
fiat. The EXISTENCE of "money", how much exists, depends on its 
circulation in the economy.



___
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] Online crypto value quote

[David T. via gnucash-user]

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, 18 Jun 2022 at 12:54, David T. via gnucash-user <
>gnucash-user@gnucash.org> wrote:
>
>> I'll note that Julie's first attachment stated that quotes were not
>> returned for certain entries. Finance::Quote is returning that error, so it
>> is installed.
>>
>> I see in Julie's attachment that her bitcoin entry is assigned to "Digital
>> Cash". The screen shot for the Yahoo! suggests that their site categorizes
>> bitcoin in CCC. I know in the past that F::Q would fail to retrieve quotes
>> unless I matched this exactly. You might try changing "Digital Cash" to
>> "CCC" and see what happens.
>>
>>
>> On June 16, 2022 10:52:16 PM EDT, Geoff  wrote:
>> >Hi David
>> >
>> >Yes, Bitcoin certainly is quoted on Yahoo:
>> >
>> >https://finance.yahoo.com/quote/BTC-USD/
>> >
>> >Julia's problem is with Finance::Quote itself, not Bitcoin, as she can't
>> get quotes for IBM.
>> >
>> >Regards
>> >
>> >Geoff
>> >=
>> >
>> >
>> >
>> >On 17/06/2022 12:42 pm, David Carlson wrote:
>> >> I don't trade bitcoin so I don't know for sure, but for a long time
>> bitcoin was not an officially recognized currency and GnuCash was not able
>> to track it unless the user jumped through some tricky hoops.  I  don't
>> know if that has changed yet. Is it quoted on Yahoo?
>> >>
>> >> On Thu, Jun 16, 2022, 8:22 PM Geoff > cleanoutmys...@gmail.com>> wrote:
>> >>
>> >> Hi Julie
>> >>
>> >> You say that you have "successfully installed" Finance::Quote.  We
>> need
>> >> to verify that is is actually working, independently of GnuCash.
>> The
>> >> easiest way to do this is to use the gnc-fq-dump utility as I
>> explained
>> >> in my email yesterday.
>> >>
>> >> You need to:
>> >> (A) Locate the folder containing the gnc-fq-dump utility
>> >> (B) Open a Terminal session and navigate to this folder
>> >> (C) Run these two commands:
>> >> perl gnc-fq-dump yahoo_json IBM
>> >> perl gnc-fq-dump yahoo_json BTC-USD
>> >>
>> >> If Finance:Quote is working correctly, you should see something like
>> >> this:
>> >>
>> >> gnc-fq-dump yahoo_json IBM
>> >> Finance::Quote fields Gnucash uses:
>> >>   symbol: IBM  <=== required
>> >> date: 06/17/2022   <=== recommended
>> >> currency: USD  <=== required
>> >> last: 135.67   <=\
>> >>  nav:  <=== one of these
>> >>price:  <=/
>> >> timezone:  <=== optional
>> >>
>> >>
>> >> gnc-fq-dump yahoo_json BTC-USD
>> >> Finance::Quote fields Gnucash uses:
>> >>   symbol: BTC-USD  <=== required
>> >> date: 06/17/2022   <=== recommended
>> >> currency: USD  <=== required
>> >> last: 20453.908<=\
>> >>  nav:  <=== one of these
>> >>price:  <=/
>> >> timezone:  <=== optional
>> >>
>> >>
>> >> Let us know the results.
>> >>
>> >> Regards
>> >>
>> >> Geoff
>> >> =
>> >>
>> >> On 16/06/2022 11:08 pm, Trang Julie wrote:
>> >>  > Thank you very much for your quick response, Geoff.
>> >>  >
>> >>  > Good news is I successfully installed the Finance::Quote version
>> >> 1.51 but still can't get online quotes.
>> >>  > I tried both Yahoo as JSON source and Alpha Vantage, and got API
>> >> key, but the notification still says the same "Unable to retrieve
>> >> quotes", as the screenshot in attached.
>> >>  >
>> >>  > I'm not sure if it's just something with the connection or data
>> >> source or I need to do something else from my end.
>> >>  >
>> >>  >
>> >>  > Sent with Proton Mail secure email.
>> >>  > --- Original Message ---
>> >>  > On Thursday, June 16th, 2022 at 7:47 PM, Geoff
>> >> mailto:cleanoutmys...@gmail.com>> wrote:
>> >>  >
>> >>  >
>> >>  >> Hi Julie
>> >>  >>
>> >>  >>> Does it mean something went wrong with Finance Quote module
>> >> install,
>> >>  >>
>> >>  >> since it doesn't show its version?
>> >>  >>
>> >>  >> Possibly. You can use the GnuCash gnc-fq-dump utility (it is a
>> Perl
>> >>  >> script) to try and narrow down the problem. You didn't mention
>> your
>> >>  >> operating system, but your screenshot looks like MacOS? Anyway,
>> on
>> >>  >> Windows you will typically find this utility in the "C:\Program
>> >> Files
>> >>  >> (x86)\gnucash\bin" directory, and you can run it from a command
>> >> prompt.
>> >>  >> See 

Re: [GNC] Bitcoin Lightning payments

[Dr. David Kirkby]

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 denominated in
> bitcoin. The lack of a currency symbol is an illusion, as they are just
> conventional symbols. Understand? In YOUR books "$" doesn't have to
> stand for dollars, it could stand for "bitcoin".
>
> Michael D Novack


I don’t suppose it would be rocket science for someone to produce a patch
file that substitutes the name of some obscure currency for BTC. I expect
one would need to  patch the XML file before upgrading to a new version of
GNUcash, but this should be doable.

At least with a Linux system, it should be fairly straightforward to create
a script to do this.


Dave

> --
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkir...@kirkbymicrowave.co.uk
https://www.kirkbymicrowave.co.uk/
Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom
___
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] Bitcoin Lightning payments

[HSC]

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 unit of 
account, might be all we can do.

HSC


--- Original Message ---
On Saturday, June 18th, 2022 at 07:10, Peter West  wrote:


> 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...@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 be in 
> secret.”
> 

> > On 18 Jun 2022, at 4:36 pm, HSC  wrote:
> > 

> > Unfortunately, the idea of pretending that 1$ = 1BTC doesn't work exactly 
> > as it should, because the Spend/Receive fields don't accept entries smaller 
> > than 0.01, even if smallest fraction for account is set to 1e-8.
> > Neither does setting the decimal places to 8 in Preferences > Numbers > 
> > Decimal places affect Spend/Receive fields. Even setting to 3 doesn't 
> > increase them beyond 2 decimal places.
> > GNC just blanks and ignores a number less than 0.01
> > 

> > That's tolerable, if we pretend that 1$ = 1 sat instead of 1 BTC, and round 
> > the the milisats of fees to nearest 10, as if they are US cents.
> > That should be close enough for the foreseeable.
> > 

> > HSC
> > 

> > --- Original Message ---
> > On Saturday, June 18th, 2022 at 04:05, 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 to 16.
> > > Will round up to 1 sat for now, since it's still of insignificant value, 
> > > but eventually that will also need some improvement.
> > 

> > 

> > 

> > > Another thing is that moving from onchain Bitcoin to its Lightning layer 
> > > channels and back is a Bitcoin transaction in itself, which involves an 
> > > onchain fee to open the channel. (Subsequent instant txs in the LN 
> > > channels are at most a few sats for substantial BTC amount, and small 
> > > payments txs often cost less than 1 sat - a fraction of a US cent in 
> > > value - as I mentioned.)
> > > So, I guess Lightning layer bitcoins will have to be represented by some 
> > > other fiat of the obscure ones that start with L perhaps.
> > 

> > 

> > 

> > > The other issue is exchanging BTC for USD stablecoins, such as USDC. Then 
> > > would have to represent that USD with some other dollar, such as the CAD 
> > > maybe?
> > 

> > 

> > 

> > > Might get error-prone. Since even Bitcoin is over a decade old now, seems 
> > > that it would be useful for GNC to allow "user-defined non-ISO" 
> > > currencies, such as "XBT" used for Bitcoin on some exchanges.
> > > Seems unlikely that central banks will ever allow such currencies to 
> > > become ISO.
> > 

> > 

> > 

> > > 

> > 

> > 

> > 

> > > HSC
> > 

> > 

> > 

> > > 

> > 

> > 

> > 

> > > --- Original Message ---
> > > On Saturday, June 18th, 2022 at 02:56, gnucash-user-requ...@gnucash.org 
> > > wrote:
> > 

> > 

> > 

> > > 

> > 

> > 

> > 

> > > 

> > 

> > 

> > 

> > > > Today's Topics:
> > 

> > 

> > 

> > > > 1. Re: Bitcoin Lightning payments (Michael or Penny Novack)
> > > > 2. Re: Online crypto value quote (David T.)
> > > > 3. Re: Online crypto value quote (Geoff)
> > 

> > 

> > 

> > > > --
> > 

> > 

> > 

> > > > Message: 1
> > > > Date: Fri, 17 Jun 2022 22:45:25 -0400
> > > > From: Michael or Penny Novack stepbystepf...@comcast.net
> > 

> > 

> > 

> > > > To: gnucash-user@gnucash.org
> > > > Subject: Re: [GNC] Bitcoin Lightning payments
> > > > Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99...@comcast.net
> > 

> > 

> > 

> > > > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 

> > 

> > 

> > > > On 6/17/2022 9:21 PM, HSC wrote:
> > 

> > 

> > 

> > > > > Hello Everyone,
> > 

> > 

> > 

> > > > > Haven?t used GC a couple years, and trying to recollect how it all 
> > > > > works.
> > 

> > 

> > 

> > > > > Current challenge is starting to work with payments and expenses that 
> > > > > are exclusively in Bitcoin.
> > 

> > 

> > 

> > > > > Has anyone experience with some commercial accounting software that 
> > > > > handles Bitcoin in an easier way as a currency that it is?
> > 

> > 

> > 

> > > > 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 

Re: [GNC] Bitcoin Lightning payments

[Peter West]

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 be in secret.”

> On 18 Jun 2022, at 4:36 pm, HSC  wrote:
> 
> 
> Unfortunately, the idea of pretending that 1$ = 1BTC doesn't work exactly as 
> it should, because the Spend/Receive fields don't accept entries smaller than 
> 0.01, even if smallest fraction for account is set to 1e-8.
> Neither does setting the decimal places to 8 in Preferences > Numbers > 
> Decimal places affect Spend/Receive fields. Even setting to 3 doesn't 
> increase them beyond 2 decimal places.
> GNC just blanks and ignores a number less than 0.01
> 
> That's tolerable, if we pretend that 1$ = 1 sat instead of 1 BTC, and round 
> the the milisats of fees to nearest 10, as if they are US cents.
> That should be close enough for the foreseeable.
> 
> HSC
> 
> --- Original Message ---
> On Saturday, June 18th, 2022 at 04:05, 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 to 16.
>> Will round up to 1 sat for now, since it's still of insignificant value, but 
>> eventually that will also need some improvement.
>> 
> 
>> Another thing is that moving from onchain Bitcoin to its Lightning layer 
>> channels and back is a Bitcoin transaction in itself, which involves an 
>> onchain fee to open the channel. (Subsequent instant txs in the LN channels 
>> are at most a few sats for substantial BTC amount, and small payments txs 
>> often cost less than 1 sat - a fraction of a US cent in value - as I 
>> mentioned.)
>> So, I guess Lightning layer bitcoins will have to be represented by some 
>> other fiat of the obscure ones that start with L perhaps.
>> 
> 
>> The other issue is exchanging BTC for USD stablecoins, such as USDC. Then 
>> would have to represent that USD with some other dollar, such as the CAD 
>> maybe?
>> 
> 
>> Might get error-prone. Since even Bitcoin is over a decade old now, seems 
>> that it would be useful for GNC to allow "user-defined non-ISO" currencies, 
>> such as "XBT" used for Bitcoin on some exchanges.
>> Seems unlikely that central banks will ever allow such currencies to become 
>> ISO.
>> 
> 
>> 
> 
>> HSC
>> 
> 
>> 
> 
>> --- Original Message ---
>> On Saturday, June 18th, 2022 at 02:56, gnucash-user-requ...@gnucash.org 
>> wrote:
>> 
> 
>> 
> 
>> 
> 
>>> Today's Topics:
>>> 
> 
>>> 1. Re: Bitcoin Lightning payments (Michael or Penny Novack)
>>> 2. Re: Online crypto value quote (David T.)
>>> 3. Re: Online crypto value quote (Geoff)
>>> 
> 
>>> --
>>> 
> 
>>> Message: 1
>>> Date: Fri, 17 Jun 2022 22:45:25 -0400
>>> From: Michael or Penny Novack stepbystepf...@comcast.net
>>> 
> 
>>> To: gnucash-user@gnucash.org
>>> Subject: Re: [GNC] Bitcoin Lightning payments
>>> Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99...@comcast.net
>>> 
> 
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>> 
> 
>>> On 6/17/2022 9:21 PM, HSC wrote:
>>> 
> 
 Hello Everyone,
 
> 
 Haven?t used GC a couple years, and trying to recollect how it all works.
 
> 
 Current challenge is starting to work with payments and expenses that are 
 exclusively in Bitcoin.
>>> 
> 
 Has anyone experience with some commercial accounting software that 
 handles Bitcoin in an easier way as a currency that it is?
>>> 
> 
>>> 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 denominated in
>>> bitcoin. The lack of a currency symbol is an illusion, as they are just
>>> conventional symbols. Understand? In YOUR books "$" doesn't have to
>>> stand for dollars, it could stand for "bitcoin".
>>> 
> 
>>> 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
> 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] Bitcoin Lightning payments

[HSC]

Unfortunately, the idea of pretending that 1$ = 1BTC doesn't work exactly as it 
should, because the Spend/Receive fields don't accept entries smaller than 
0.01, even if smallest fraction for account is set to 1e-8.
Neither does setting the decimal places to 8 in Preferences > Numbers > Decimal 
places affect Spend/Receive fields. Even setting to 3 doesn't increase them 
beyond 2 decimal places.
GNC just blanks and ignores a number less than 0.01

That's tolerable, if we pretend that 1$ = 1 sat instead of 1 BTC, and round the 
the milisats of fees to nearest 10, as if they are US cents.
That should be close enough for the foreseeable.

HSC

--- Original Message ---
On Saturday, June 18th, 2022 at 04:05, 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 to 16.
> Will round up to 1 sat for now, since it's still of insignificant value, but 
> eventually that will also need some improvement.
> 

> Another thing is that moving from onchain Bitcoin to its Lightning layer 
> channels and back is a Bitcoin transaction in itself, which involves an 
> onchain fee to open the channel. (Subsequent instant txs in the LN channels 
> are at most a few sats for substantial BTC amount, and small payments txs 
> often cost less than 1 sat - a fraction of a US cent in value - as I 
> mentioned.)
> So, I guess Lightning layer bitcoins will have to be represented by some 
> other fiat of the obscure ones that start with L perhaps.
> 

> The other issue is exchanging BTC for USD stablecoins, such as USDC. Then 
> would have to represent that USD with some other dollar, such as the CAD 
> maybe?
> 

> Might get error-prone. Since even Bitcoin is over a decade old now, seems 
> that it would be useful for GNC to allow "user-defined non-ISO" currencies, 
> such as "XBT" used for Bitcoin on some exchanges.
> Seems unlikely that central banks will ever allow such currencies to become 
> ISO.
> 

> 

> HSC
> 

> 

> --- Original Message ---
> On Saturday, June 18th, 2022 at 02:56, gnucash-user-requ...@gnucash.org wrote:
> 

> 

> 

> > Today's Topics:
> > 

> > 1. Re: Bitcoin Lightning payments (Michael or Penny Novack)
> > 2. Re: Online crypto value quote (David T.)
> > 3. Re: Online crypto value quote (Geoff)
> > 

> > --
> > 

> > Message: 1
> > Date: Fri, 17 Jun 2022 22:45:25 -0400
> > From: Michael or Penny Novack stepbystepf...@comcast.net
> > 

> > To: gnucash-user@gnucash.org
> > Subject: Re: [GNC] Bitcoin Lightning payments
> > Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99...@comcast.net
> > 

> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 

> > On 6/17/2022 9:21 PM, HSC wrote:
> > 

> > > Hello Everyone,
> > > 

> > > Haven?t used GC a couple years, and trying to recollect how it all works.
> > > 

> > > Current challenge is starting to work with payments and expenses that are 
> > > exclusively in Bitcoin.
> > 

> > > Has anyone experience with some commercial accounting software that 
> > > handles Bitcoin in an easier way as a currency that it is?
> > 

> > 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 denominated in
> > bitcoin. The lack of a currency symbol is an illusion, as they are just
> > conventional symbols. Understand? In YOUR books "$" doesn't have to
> > stand for dollars, it could stand for "bitcoin".
> > 

> > Michael D Novack

signature.asc
Description: OpenPGP digital signature
___
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.