Re: [GNC] problem setting the price of a share

[Christian Pinedo Zamalloa]

If instead of a mailing list it was a social network, I just would like
your reply! Thanks again for your input and references,

--
Christian Pinedo Zamalloa (zako)
Sent from my mobile device, please excuse brevity or typos

El mié., 19 sept. 2018 1:22, David Carlson 
escribió:

> There have been several discussions over the years around various aspects
> of the topics of numeric accuracy, displaying accurate values vs easily
> readable values, whether GnuCash records do or do not match brokers'
> reports or newspaper stock price listings, and even whether the GnuCash
> price database is properly configured and whether data is correctly
> extracted from it for various reports. If you want to research the topic
> further there are several threads in this user maillist going back a decade
> or more.
>
> I just searched the bug database and found several open bug reports which
> directly involve these points.
> *Bug 787813* 
> *Bug 793556* 
> *Bug 638175* 
> *Bug 410060* 
>
> GnuCash was changed in release 2.6.8, dated late 2015 to usually store
> prices in decimal format when they were entered in decimal format, but
> there was a regression in the 2.7.x development series leading up  to the
> 3.x releases reverting to the fractional display currently seen.  Bug
> 793556 has already been filed regarding the fractional format as related to
> CSV imports and exports, but it does not extend to use of those values in
> spreadsheets.  The fractional format is the raw display of the number
> format used internally for certain calculations requiring high accuracy,
> and a few users actually prefer to see prices displayed in that format, so
> it is not likely to be completely hidden.
>
> John Ralls points out in his reply that release 3.3 will fix your first
> concern as well as it can in this real world.
>
> David C
>
> On Tue, Sep 18, 2018 at 4:22 PM Christian Pinedo Zamalloa <
> chr.pin...@gmail.com> wrote:
>
>> Hi David,
>>
>> At the end I was able to get properly the price by skipping it and
>> letting to GnuCash to calculate it as you suggested. However, I think that
>> this might be a kind of bug, because if I insert the price in decimal
>> format, it shouldn't be modified and the total amount should be calculated
>> accordingly.
>>
>> Regarding the fractional format of prices, one more issue. Apart from
>> being more difficult to read, when transactions are exported to CSV, the
>> fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
>> opened with calc/excel we need to modify all the prices to be considered
>> numbers not strings (i.e. insert "=123 + 3/45").
>>
>> Thanks for your suggestions!!
>>
>>
>>
>> El sáb., 15 sept. 2018 a las 16:26, David Carlson (<
>> david.carlson@gmail.com>) escribió:
>>
>>> As I stated in my reply, enter the number of shares and total amount,
>>> Skip the price, let GnuCash take care of that.
>>>
>>> David C
>>>
>>> On Sat, Sep 15, 2018 at 9:21 AM Christian Pinedo Zamalloa <
>>> chr.pin...@gmail.com> wrote:
>>>
 Hi David,

 I also agree with you that the fractional format is more difficult to
 read than decimal and I also hope to return to decimal format or at least
 to be able to choose between decimal or fractional format.

 Regarding my problem with price, I insert the number of shares, the
 prices (in decimal format) and press enter. The decimal formal is converted
 to fractional format, but fractional number is not the same that I inserted
 before. :-(

 Any idea?

 --
 Christian Pinedo Zamalloa (zako)
 Sent from my mobile device, please excuse brevity or typos

 El sáb., 15 sept. 2018 14:49, David Carlson <
 david.carlson@gmail.com> escribió:

> Christian Pinedo Zamalloa
>
> You have discovered that it is impossible to have all three values
> shares, price and total exactly as reported by your broker because he
> usually has to round off one of the numbers.  The solution is to let
> GnuCash set the price after you enter the number of shares and the total
> amount.  Actually, GnuCash is closer to being correct than your broker is.
>
> You have also discovered that in release 3.3 GnuCash shows the number
> of shares in fractional format, which has the technical advantage of being
> very accurate, if very hard to read.  I believe that in the future GnuCash
> may be changed back to show the number of shares in decimal format to be
> easier to read, if less accurate.
>
> David C
>
>
>
> On Sat, Sep 15, 2018 at 4:16 AM Christian Pinedo Zamalloa <
> chr.pin...@gmail.com> wrote:
>
>> Hello,
>>
>> I have problems to set the correct price of a share that I am selling.
>>
>> I try to put 

Re: [GNC] problem setting the price of a share

[John Ralls]

No, GnuCash has never, ever, stored any number in floating point. Stored 
numbers in GnuCash have been rationals from the very beginning. It was changed 
in 2.6.8 to always round prices for display so that they’d always appear in 
decimal form to the user, but the code that did it was overwhelmed by the 
increased precision in GnuCash 3 so prices started displaying as rationals 
again. That’s fixed for 3.3, though there’s a preference to override it and 
display rationals if the user prefers the exact value.

Most calculations in GnuCash are in rationals. There are a couple of 
exceptions, the most notable being interest/time-value-of-money calculations 
because they require exponentiation and there isn’t yet a rational 
exponentiation operator in GnuCash. I’ve started writing one, but set it aside 
to deal with more pressing bugs.

Regards,
John Ralls


> On Sep 18, 2018, at 4:22 PM, David Carlson  
> wrote:
> 
> There have been several discussions over the years around various aspects
> of the topics of numeric accuracy, displaying accurate values vs easily
> readable values, whether GnuCash records do or do not match brokers'
> reports or newspaper stock price listings, and even whether the GnuCash
> price database is properly configured and whether data is correctly
> extracted from it for various reports. If you want to research the topic
> further there are several threads in this user maillist going back a decade
> or more.
> 
> I just searched the bug database and found several open bug reports which
> directly involve these points.
> *Bug 787813* 
> *Bug 793556* 
> *Bug 638175* 
> *Bug 410060* 
> 
> GnuCash was changed in release 2.6.8, dated late 2015 to usually store
> prices in decimal format when they were entered in decimal format, but
> there was a regression in the 2.7.x development series leading up  to the
> 3.x releases reverting to the fractional display currently seen.  Bug
> 793556 has already been filed regarding the fractional format as related to
> CSV imports and exports, but it does not extend to use of those values in
> spreadsheets.  The fractional format is the raw display of the number
> format used internally for certain calculations requiring high accuracy,
> and a few users actually prefer to see prices displayed in that format, so
> it is not likely to be completely hidden.
> 
> John Ralls points out in his reply that release 3.3 will fix your first
> concern as well as it can in this real world.
> 
> David C
> 
> On Tue, Sep 18, 2018 at 4:22 PM Christian Pinedo Zamalloa <
> chr.pin...@gmail.com> wrote:
> 
>> Hi David,
>> 
>> At the end I was able to get properly the price by skipping it and letting
>> to GnuCash to calculate it as you suggested. However, I think that this
>> might be a kind of bug, because if I insert the price in decimal format, it
>> shouldn't be modified and the total amount should be calculated accordingly.
>> 
>> Regarding the fractional format of prices, one more issue. Apart from
>> being more difficult to read, when transactions are exported to CSV, the
>> fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
>> opened with calc/excel we need to modify all the prices to be considered
>> numbers not strings (i.e. insert "=123 + 3/45").
>> 
>> Thanks for your suggestions!!
>> 
>> 
>> 
>> El sáb., 15 sept. 2018 a las 16:26, David Carlson (<
>> david.carlson@gmail.com>) escribió:
>> 
>>> As I stated in my reply, enter the number of shares and total amount,
>>> Skip the price, let GnuCash take care of that.
>>> 
>>> David C
>>> 
>>> On Sat, Sep 15, 2018 at 9:21 AM Christian Pinedo Zamalloa <
>>> chr.pin...@gmail.com> wrote:
>>> 
 Hi David,
 
 I also agree with you that the fractional format is more difficult to
 read than decimal and I also hope to return to decimal format or at least
 to be able to choose between decimal or fractional format.
 
 Regarding my problem with price, I insert the number of shares, the
 prices (in decimal format) and press enter. The decimal formal is converted
 to fractional format, but fractional number is not the same that I inserted
 before. :-(
 
 Any idea?
 
 --
 Christian Pinedo Zamalloa (zako)
 Sent from my mobile device, please excuse brevity or typos
 
 El sáb., 15 sept. 2018 14:49, David Carlson 
 escribió:
 
> Christian Pinedo Zamalloa
> 
> You have discovered that it is impossible to have all three values
> shares, price and total exactly as reported by your broker because he
> usually has to round off one of the numbers.  The solution is to let
> GnuCash set the price after you enter the number of shares and the total
> amount.  Actually, GnuCash is closer to being correct than your broker 

Re: [GNC] problem setting the price of a share

[David Carlson]

There have been several discussions over the years around various aspects
of the topics of numeric accuracy, displaying accurate values vs easily
readable values, whether GnuCash records do or do not match brokers'
reports or newspaper stock price listings, and even whether the GnuCash
price database is properly configured and whether data is correctly
extracted from it for various reports. If you want to research the topic
further there are several threads in this user maillist going back a decade
or more.

I just searched the bug database and found several open bug reports which
directly involve these points.
*Bug 787813* 
*Bug 793556* 
*Bug 638175* 
*Bug 410060* 

GnuCash was changed in release 2.6.8, dated late 2015 to usually store
prices in decimal format when they were entered in decimal format, but
there was a regression in the 2.7.x development series leading up  to the
3.x releases reverting to the fractional display currently seen.  Bug
793556 has already been filed regarding the fractional format as related to
CSV imports and exports, but it does not extend to use of those values in
spreadsheets.  The fractional format is the raw display of the number
format used internally for certain calculations requiring high accuracy,
and a few users actually prefer to see prices displayed in that format, so
it is not likely to be completely hidden.

John Ralls points out in his reply that release 3.3 will fix your first
concern as well as it can in this real world.

David C

On Tue, Sep 18, 2018 at 4:22 PM Christian Pinedo Zamalloa <
chr.pin...@gmail.com> wrote:

> Hi David,
>
> At the end I was able to get properly the price by skipping it and letting
> to GnuCash to calculate it as you suggested. However, I think that this
> might be a kind of bug, because if I insert the price in decimal format, it
> shouldn't be modified and the total amount should be calculated accordingly.
>
> Regarding the fractional format of prices, one more issue. Apart from
> being more difficult to read, when transactions are exported to CSV, the
> fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
> opened with calc/excel we need to modify all the prices to be considered
> numbers not strings (i.e. insert "=123 + 3/45").
>
> Thanks for your suggestions!!
>
>
>
> El sáb., 15 sept. 2018 a las 16:26, David Carlson (<
> david.carlson@gmail.com>) escribió:
>
>> As I stated in my reply, enter the number of shares and total amount,
>> Skip the price, let GnuCash take care of that.
>>
>> David C
>>
>> On Sat, Sep 15, 2018 at 9:21 AM Christian Pinedo Zamalloa <
>> chr.pin...@gmail.com> wrote:
>>
>>> Hi David,
>>>
>>> I also agree with you that the fractional format is more difficult to
>>> read than decimal and I also hope to return to decimal format or at least
>>> to be able to choose between decimal or fractional format.
>>>
>>> Regarding my problem with price, I insert the number of shares, the
>>> prices (in decimal format) and press enter. The decimal formal is converted
>>> to fractional format, but fractional number is not the same that I inserted
>>> before. :-(
>>>
>>> Any idea?
>>>
>>> --
>>> Christian Pinedo Zamalloa (zako)
>>> Sent from my mobile device, please excuse brevity or typos
>>>
>>> El sáb., 15 sept. 2018 14:49, David Carlson 
>>> escribió:
>>>
 Christian Pinedo Zamalloa

 You have discovered that it is impossible to have all three values
 shares, price and total exactly as reported by your broker because he
 usually has to round off one of the numbers.  The solution is to let
 GnuCash set the price after you enter the number of shares and the total
 amount.  Actually, GnuCash is closer to being correct than your broker is.

 You have also discovered that in release 3.3 GnuCash shows the number
 of shares in fractional format, which has the technical advantage of being
 very accurate, if very hard to read.  I believe that in the future GnuCash
 may be changed back to show the number of shares in decimal format to be
 easier to read, if less accurate.

 David C



 On Sat, Sep 15, 2018 at 4:16 AM Christian Pinedo Zamalloa <
 chr.pin...@gmail.com> wrote:

> Hello,
>
> I have problems to set the correct price of a share that I am selling.
>
> I try to put the value "128,181208053691" which is automatically
> converted
> by GnuCash when i push enter key to "128 + 64/377" whose real value is
> "128,169761". Furthermore, I checked if I insert value "1", it is
> automatically converted by GnuCash to value "1+3/377" (1,007958).
>
> I don't know how to solve this mesh. Am I doing something wrong?
>
> --
> zako
> ___

Re: [GNC] problem setting the price of a share

[John Ralls]

> On Sep 18, 2018, at 2:22 PM, Christian Pinedo Zamalloa  
> wrote:
> 
> Hi David,
> 
> At the end I was able to get properly the price by skipping it and letting
> to GnuCash to calculate it as you suggested. However, I think that this
> might be a kind of bug, because if I insert the price in decimal format, it
> shouldn't be modified and the total amount should be calculated accordingly.
> 
> Regarding the fractional format of prices, one more issue. Apart from being
> more difficult to read, when transactions are exported to CSV, the
> fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
> opened with calc/excel we need to modify all the prices to be considered
> numbers not strings (i.e. insert "=123 + 3/45").
> 
> Thanks for your suggestions!!

Christian,

The presentation to the user is 
https://bugs.gnucash.org/show_bug.cgi?id=794755, fixed for 3.3.

As for recalculating invalid prices, it's an unavoidable consequence of real 
money having a limited number of usable fractional values. GnuCash doesn't 
actually store prices, it calculates them as the ratio between the amount 
(shares) and value (money). In general you can't have a fraction of a share for 
regular stock and you can't have a fraction of currency that's not an 
integer/100. If you enter a price that produces a fractional number of shares 
or "pennies" then GnuCash will round the amount or the value to be a legal 
value and the price will get recalculated accordingly. The alternative would be 
to refuse to accept the split and require that you figure out the correct price 
yourself, which seems a bit cumbersome.

Regards,
John Ralls

___
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] problem setting the price of a share

[Christian Pinedo Zamalloa]

Hi David,

At the end I was able to get properly the price by skipping it and letting
to GnuCash to calculate it as you suggested. However, I think that this
might be a kind of bug, because if I insert the price in decimal format, it
shouldn't be modified and the total amount should be calculated accordingly.

Regarding the fractional format of prices, one more issue. Apart from being
more difficult to read, when transactions are exported to CSV, the
fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
opened with calc/excel we need to modify all the prices to be considered
numbers not strings (i.e. insert "=123 + 3/45").

Thanks for your suggestions!!



El sáb., 15 sept. 2018 a las 16:26, David Carlson (<
david.carlson@gmail.com>) escribió:

> As I stated in my reply, enter the number of shares and total amount,
> Skip the price, let GnuCash take care of that.
>
> David C
>
> On Sat, Sep 15, 2018 at 9:21 AM Christian Pinedo Zamalloa <
> chr.pin...@gmail.com> wrote:
>
>> Hi David,
>>
>> I also agree with you that the fractional format is more difficult to
>> read than decimal and I also hope to return to decimal format or at least
>> to be able to choose between decimal or fractional format.
>>
>> Regarding my problem with price, I insert the number of shares, the
>> prices (in decimal format) and press enter. The decimal formal is converted
>> to fractional format, but fractional number is not the same that I inserted
>> before. :-(
>>
>> Any idea?
>>
>> --
>> Christian Pinedo Zamalloa (zako)
>> Sent from my mobile device, please excuse brevity or typos
>>
>> El sáb., 15 sept. 2018 14:49, David Carlson 
>> escribió:
>>
>>> Christian Pinedo Zamalloa
>>>
>>> You have discovered that it is impossible to have all three values
>>> shares, price and total exactly as reported by your broker because he
>>> usually has to round off one of the numbers.  The solution is to let
>>> GnuCash set the price after you enter the number of shares and the total
>>> amount.  Actually, GnuCash is closer to being correct than your broker is.
>>>
>>> You have also discovered that in release 3.3 GnuCash shows the number of
>>> shares in fractional format, which has the technical advantage of being
>>> very accurate, if very hard to read.  I believe that in the future GnuCash
>>> may be changed back to show the number of shares in decimal format to be
>>> easier to read, if less accurate.
>>>
>>> David C
>>>
>>>
>>>
>>> On Sat, Sep 15, 2018 at 4:16 AM Christian Pinedo Zamalloa <
>>> chr.pin...@gmail.com> wrote:
>>>
 Hello,

 I have problems to set the correct price of a share that I am selling.

 I try to put the value "128,181208053691" which is automatically
 converted
 by GnuCash when i push enter key to "128 + 64/377" whose real value is
 "128,169761". Furthermore, I checked if I insert value "1", it is
 automatically converted by GnuCash to value "1+3/377" (1,007958).

 I don't know how to solve this mesh. Am I doing something wrong?

 --
 zako
 ___
 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.

>>>

-- 
Christian Pinedo Zamalloa (zako)
PGP keyID: 0xdb577d4ee6ffbd55
PGP Fgprt: A895 7C11 84F6 30B4 4938  32A4 9306 DFD0 CDE4 B542
___
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] Can't save counter number format

[Ndimi Bodika]

Hi,
Using gnucash Build ID: 3.2+ (2018-06-24), on windows 10
I've been trying to format my invoice numbers on the counters using
different fomats without success, tried "2018 - %05li", "2018 - %05lli",
"2018 - %05lu" , etc ...
I also noticed that it is not saving the format in the counters tab either.
Every time I enter the format and click OK, the next time I open the
counters tab the entry is empty. It does not seem to save the number
format. Is this a bug or am I missing something ?

-- 
The only constant in life is change.
___
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] Disconnect between balance on client list and account statement

[Adrien Monteleone]

Roger,

Glad to see you resolved the discrepancy. I too have had to resort to 
completely re-entering some transactions in a few cases. Thank you for 
documenting this for posterity.

Also, consider the utility of the Receivable Aging Report if you haven’t looked 
at it already. It can also show customers/amounts by how long they are past 
due, and you can sort the list by amount owed. (ascending or descending) 
Clicking the total owed brings up the Customer Report/Statement.

Regards,
Adrien

> On Sep 18, 2018, at 1:08 PM, Roger Oliver  wrote:
> 
> Adrien,
>  
> In August I asked about a disconnect between the balance on the customer 
> overview and the balance on the customer statement. Your answer is below. 
> Just now getting around to fixing the problem. For your amazement and 
> amusement and for anyone else who encounters a similar problem, here are the 
> steps I took:
>  
>   • Created a customer statement dated back to the earliest transactions 
> for this customer
>   • Unposted and reposted 4 invoices that were paid from a single advance 
> payment
>   • Deleted the advance payment 
>   • Received the advance payment on the date originally paid to pay the 
> first of the 4 invoices
>   • Paid each of the remaining 3 invoices from the balance of the advance 
> payment. 
>   • Created an invoice missing from June and paid it with the remaining 
> balance. 
>  
> Now the balances on the customer overview and the customer statement match. I 
> use the customer overview to follow up on late payments by sorting on the 
> amount due so it is helpful that the balances on the statement and on the 
> customer overview match.
>  
> Thanks again,
> Roger
>  
> I think this is fixable. You should not need to create a new customer account.
>  
> By ?Customer Statement? I?m presuming you mean the ?Customer Report? correct?
>  
> If so, change the dates to reflect the entire time she?s been a customer. If 
> everything is paid and there are no remaining pre-payments (deposits) it 
> should balance to zero. You can check for remaining deposits by trying to 
> Process Payment on her account. If any pre-payment still shows up, then it 
> has not been applied. (same with any invoices that show up)
>  
> Now, run a Reports > Business > Receivable Aging report. It should show she 
> has a zero balance. If not, double check the options to make sure the ?To? 
> date matches the end date of the Customer Report. (usually ?Today?) These 
> numbers *should* match what is shown on the Customer Overview Balance column.
>  
> If when these dates match, you still have non-zero balances, then there are 
> one or more invoices posted for her that aren?t paid. You?ll have to track 
> them down. Do an invoice find with her as the customer and check them all to 
> make sure they are paid. (one possibility is you might have a duplicate 
> somewhere.)
>  
> If the balances are zero when the dates match, but non-zero when you extend 
> the ?to? past ?today? then you?ve posted a future invoice to her account and 
> your report option for the Aging Report (and possibly the overview does this 
> as well) is set to that later date. She might be current ?today? but based on 
> what is posted, does (or will) owe $1500.
>  
> So the end result is there is likely a misapplied payment or not-applied 
> payment, or a future dated invoice. If you posted and un-posted an invoice, 
> it is possible the payment was not successfully re-applied and you need to 
> re-associate it to the proper invoice.
>  
> 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] Disconnect between balance on client list and account statement

[rmomxtx]

Adrien,

 

In August I asked about a disconnect between the balance on the customer
overview and the balance on the customer statement. Your answer is below.
Just now getting around to fixing the problem. For your amazement and
amusement and for anyone else who encounters a similar problem, here are the
steps I took:

 

1.  Created a customer statement dated back to the earliest transactions
for this customer
2.  Unposted and reposted 4 invoices that were paid from a single
advance payment
3.  Deleted the advance payment 
4.  Received the advance payment on the date originally paid to pay the
first of the 4 invoices
5.  Paid each of the remaining 3 invoices from the balance of the
advance payment. 
6.  Created an invoice missing from June and paid it with the remaining
balance. 

 

Now the balances on the customer overview and the customer statement match.
I use the customer overview to follow up on late payments by sorting on the
amount due so it is helpful that the balances on the statement and on the
customer overview match.

 

Thanks again,

Roger

 

I think this is fixable. You should not need to create a new customer
account.

 

By ?Customer Statement? I?m presuming you mean the ?Customer Report?
correct?

 

If so, change the dates to reflect the entire time she?s been a customer. If
everything is paid and there are no remaining pre-payments (deposits) it
should balance to zero. You can check for remaining deposits by trying to
Process Payment on her account. If any pre-payment still shows up, then it
has not been applied. (same with any invoices that show up)

 

Now, run a Reports > Business > Receivable Aging report. It should show she
has a zero balance. If not, double check the options to make sure the ?To?
date matches the end date of the Customer Report. (usually ?Today?) These
numbers *should* match what is shown on the Customer Overview Balance
column.

 

If when these dates match, you still have non-zero balances, then there are
one or more invoices posted for her that aren?t paid. You?ll have to track
them down. Do an invoice find with her as the customer and check them all to
make sure they are paid. (one possibility is you might have a duplicate
somewhere.)

 

If the balances are zero when the dates match, but non-zero when you extend
the ?to? past ?today? then you?ve posted a future invoice to her account and
your report option for the Aging Report (and possibly the overview does this
as well) is set to that later date. She might be current ?today? but based
on what is posted, does (or will) owe $1500.

 

So the end result is there is likely a misapplied payment or not-applied
payment, or a future dated invoice. If you posted and un-posted an invoice,
it is possible the payment was not successfully re-applied and you need to
re-associate it to the proper invoice.

 

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] Error importing quicken 2017 qif / qfx

[Maf. King]

On Monday, 17 September 2018 17:10:10 BST Diogo Maciel wrote:
> I think it's a bug in the 3.2 version. Installed the 2.6 version and it
> imported without problems
> 

Or, logically, it could be a bug in 2.6.x to allow something bogus into GC 
(that has been fixed in 3.x)? 

0.02
Maf.



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