It is working fine here on MacOS and Linux Mint.
Can you replicate it with a fresh test book using all default settings?
Regards,
Adrien
On 11/30/23 10:25 PM, Michael Campbell via gnucash-user wrote:
Fixed. Eventually.
I unchecked the "Numbers, Date, Time" -> "Automatic decimal point" check
Is there any way to get a report showing amounts 'as entered'. That is,
are all foreign transactions converted by those rules in aggregate, or
is there a method for getting the actual converted amounts tallied? (for
example, the exchange rate might vary enough from the beginning of the
report
Fixed. Eventually.
I unchecked the "Numbers, Date, Time" -> "Automatic decimal point" check
box in settings where it was set to 2 decimal places and now amounts
will be calculated correctly.
Is anyone else able to replicate this bug?
Regards,
Michael Campbell
On 12/1/23 09:27, Adrien
> On Nov 30, 2023, at 16:40, Derek Atkins wrote:
>
> Even more, the REPORTS only use #2, not #1, to figure out the "value" of
> an account in another currency.
Not exactly. Most reports have a Price Source option that allows you to select
how commodity prices and currency exchange rates are
Hi,
GnuCash stores the exchange rates in two ways:
1) In the transaction, it lets you record the exact conversion.
2) In the priceDB, it lets you input one price per day.
When you enter a transaction like #1, gnucash will automatically create a
pricedb entry for you. In other words, you do NOT
On Thu, 30 Nov 2023 at 20:50, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> As Derek noted, this is likely not a bug, but an issue with your pricedb
> in your main file.
>
> I too lost the plot, and forgot that those reports can target which
> price to use for such cases.
>
> Your
On Thu, 30 Nov 2023 at 20:55, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> Have you run Actions > Check & Repair > Check & Repair All?
>
> There might be something amiss that such scrubbing can clean up.
>
> Regards,
> Adrien
I have run that many times. However, I never thought
MIchael
That still works as expected in GnuCash 5.4 running on Linux Mint. I entered a
transaction for $15.61 credit to my bank account, entered the next split as
$15.61/11 and it was calculated as $1.42 with $14.19 going to the Imbalance
account (I hit enter after entering the second split). I
That sounds like a 'smallest commodity fraction' issue off the top of my
head.
Check your settings for your affected currency.
Another place to check is the setting for automatic decimal points.
Regards,
Adrien
On 11/30/23 4:20 PM, Michael Campbell via gnucash-user wrote:
Hello All,
Long
I could be mistaken, but I don't think uncommitted transactions are
written using the SQL backends. An edit perhaps, but not a new transaction.
Note, the OP is referencing a crash, or leaving GnuCash open, forgetting
about a pending edit to be committed, and restarting the computer. I
think
Hello All,
Long time lurker here, first time poster. I have been learning to use
GNU Cash for my personal finances and now business for the past 10
years. I am still learning.
When entering Goods and Services Tax for an entry, I used to just be
able to divide the total cost by eleven in the
I'm assuming you are using XML. In that case the "Save" button does appear
from being greyed out and you are indicated on close. Of course this is
global and not individual indications that you would like.
The SQL database will save as you go.
I'm in the other camp where I *don't* want to
Have you run Actions > Check & Repair > Check & Repair All?
There might be something amiss that such scrubbing can clean up.
Regards,
Adrien
On 11/30/23 9:53 AM, David Kirkby wrote:
This may be related to my other issues, but I sometimes see this.
I just deleted all my USD transactions,
As Derek noted, this is likely not a bug, but an issue with your pricedb
in your main file.
I too lost the plot, and forgot that those reports can target which
price to use for such cases.
Your options then are to:
1. Play with the price target option
2. Edit, or delete the offending
First, yes, that warning is for when you try to delete the *Invoice*,
not the payment. (same for Bills with Vendors)
Second, as you may have noticed, inline images are not possible with
this list, you have to attach them separately. Because of that, if you
can, please give them some
Have you looked at https://bugs.gnucash.org/show_bug.cgi?id=686051, which
was reported 13 years ago?
On Thu, Nov 30, 2023 at 12:27 PM Glenn Fowler wrote:
> Hi that is expected behavior with xml, have you tried the database format?
>
> On Thu, Nov 30, 2023, 1:05 PM David G. Pickett via
Well, it took some time, but the problem seems to be solved. I went
back a couple of years and eventually found some errors associated with
some fraudulent activity on my account. I also did some work fixing
errors in an associated savings account. When I finished that, all my
previously
Hi that is expected behavior with xml, have you tried the database format?
On Thu, Nov 30, 2023, 1:05 PM David G. Pickett via gnucash-user <
gnucash-user@gnucash.org> wrote:
> One problem with gnucash is inadvertently uncommitted modified
> transactions. It's be nice if the tab lit up if that
One problem with gnucash is inadvertently uncommitted modified transactions.
It's be nice if the tab lit up if that account included such, so I can commit
it before wandering off. If the system is rebooted or gnucash is killed for
batch stock price updates, these modifications are lost, even
Although the invoice was showing as unpaid as I mentioned, I forcibly quit
GnuCash, then saw the $591 invoice was marked as paid. But when I looked at
the trial balance I saw this
[image: image.png]
for a $591 invoice. But there's no way GnuCash should have any idea how any
GBP that was, as it was
This may be related to my other issues, but I sometimes see this.
I just deleted all my USD transactions, leaving GBP and EUR untouched and
verified that both the P and trial balance showed a zero balance for
goods and services sold in USD.
Then I tried posting the first invoice and then paying
In this data file there is a transaction that converts from 540 to 424.
It sounds like that is correct. My only guess as to the reporting is that
there are PriceDB entries in your real data file that are "incorrect" for
the actual transaction days. In the data file you posted, there is only a
On Thu, 30 Nov 2023 at 12:13, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> Apparently so!
>
I have lost the plot I think.
I think there's a bug in the reporting.
Here's a demo account, with the GBP shown correctly for USD sales, but the
value of the USD sales is not given. I
Apparently so!
You can't delete the *invoice* but you can delete the payment.
I don't ever recall anything different and I've been using GnuCash for
10+ years.
Of course, you do get the confirmation for deleting the payment, but it
isn't an error.
Deleting the payment *should* 'unattach'
On Thu, 30 Nov 2023 at 09:18, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> Once again - please remember to reply to the list...
>
OOps.
>
> It was several replies up the thread, but I was replying to your point
> about being able to delete payments for only some currencies.
Once again - please remember to reply to the list...
-
It was several replies up the thread, but I was replying to your point
about being able to delete payments for only some currencies. (though
you've now discovered that currency isn't a limitation)
Here was my posting:
Let's get
On Thu, 30 Nov 2023 at 03:48, Alan Hopkins wrote:
>Hello David
>We receive and pay for a multitude of currencies. This made life
>complicated for a small business so we decided to use a FX service - we
>use OFX because we managed to get to them in their early days and were
>
27 matches
Mail list logo
