[GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

[Wm via gnucash-devel]

Background: My gnc TB has been wrong for years.  This hasn't been a 
problem for me because I can do my own TB in sql and satisfy myself all 
is relatively well with my accounts.  Over the last week or so I decided 
to try again and I think the gnc TB report is b0rked.


Looking at the bug list, I'm not making a new observation, the gnc TB is 
not a feature of which to be proud but I think I can help.


The problems seem to be centered around two things:

1. using currency other than your home currency
2. related to that, using trading accounts

Guess what?  If it was that simple it would have been solved by now, right?

I have loads of tx in a number of currencies using trading accounts that 
don't make the gnc TB throw a wobbly but have identified the first that 
makes it go wrong.


So, let's look at a tx that does make it go wrong, maybe someone will 
help me to think, it is possible I've looked at this for too long and am 
missing something really obvious.


===
Liabilities:Loans:T:T ZAR Dr 7,963.46
Liabilities:Loans:T:T USD Cr 771.22
===

The numbers are real, I've changed the account names slightly, I've 
separated this particular tx as the first that makes the gnc TB go wrong 
and does actually balance by my understanding of accounting and mathematics.


The prices look right, the actual exchange rate is real, what is wrong?

Things to consider:

If the price to be used is the issue, is the gnc TB using the right 
price? My answer may be "yes, usually it does use the right price, I 
can't work out why it sometimes doesn't"


Does this raise an accounting honesty issue?

I think it does.

If you need to roll your own to get a TB from a transaction stream 
something isn't right.


Alternatively, please help me to see what is wrong with my tx.

have a joke: Trump wants to be the Dutch boy, first he needs a dyke, 
then he realises his fingers are tiny :)


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Further feedback

[Christopher Lam]

Well I've been schooled.

Please refresh and try again.

The headers should match the desired report *post* reconciliation.

The transactions reported are: uncleared, cleared, and reconciliation 
whereby split-reconciliation-date = account's last-reconciliation-date.


On 9/2/19 10:19 am, Steve Butler wrote:
Sorry for top posting.  Checked the transaction report items.  One is 
Reconciled Date.   That date matches the bank statement date on which 
it was reconciled.


How does that report get that date per transaction if the field 
doesn't exist?


On Fri, Feb 8, 2019, 17:52 Christopher Lam  wrote:


On 9/2/19 7:49 am, Stephen M. Butler wrote:
> On 2/8/19 5:12 AM, Christopher Lam wrote:
>> I've been experimenting and I think there's a logic error in your
>> thinking -- *during* reconciliation, until it's complete, all
>> 'reconciled' transactions are labelled 'cleared'. Reconciled
>> transactions are, so to speak, gone and don't need to be shown on a
>> reconciliation report.
> The reconciliation report should run just after reconciliation has
> finished.  Therefore, the just reconciled items will be marked as
> reconciled.

I do agree in principle... however the internal logic of GnuCash
dictates that there is no such thing as "just reconciled items".

Consider a very busy bank account needing regular
reconciliation... on
15-january you try reconcile but you've written and recorded a
check for
$53.50 on 20-december which is still not cleared. This $53.50 will
remain unreconciled ("outstanding") causing a discrepancy of $53.50
between your 15-January bank statement, and your book. You reconcile,
skipping the $53.50 amount, and all's well.

On 15-february the bank statement arrives, and the $53.50 check has
cleared on 19-january. The $53.50 status changes from
(n)unreconciled to
(c)cleared. Additionally all intermediate transactions are
cleared. Your
15-february bank statement now matches your books.

According to my suggestions above logic the $53.50 will be counted in
the 'cleared' header, and be present in the reconciliation report.
You
will afterwards then complete the reconciliation, which converts all
'c'leared to 'y'reconciled.

If we were to follow your logic, and if we run the reconciliation
report
on 15-february, and if we *aim* to look for the 'just-reconciled'
items,
we will definitely miss the $53.50 transaction dated 20-December
because
it's now reconciled/"archived". Remember the transactions do *NOT*
have
a 'reconciliation date' so we cannot look for them using a simple
query.
Only accounts have a last-reconciliation-date. We will *not* find
them
by querying 'reconciliation-date minus 1 day'.

Logically you're not wrong but GnuCash internal logic will dictate
the
above process must be followed.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Further feedback

[John Ralls]

> On Feb 8, 2019, at 5:52 PM, Christopher Lam  wrote:
> 
> On 9/2/19 7:49 am, Stephen M. Butler wrote:
>> On 2/8/19 5:12 AM, Christopher Lam wrote:
>>> I've been experimenting and I think there's a logic error in your
>>> thinking -- *during* reconciliation, until it's complete, all
>>> 'reconciled' transactions are labelled 'cleared'. Reconciled
>>> transactions are, so to speak, gone and don't need to be shown on a
>>> reconciliation report.
>> The reconciliation report should run just after reconciliation has
>> finished.  Therefore, the just reconciled items will be marked as
>> reconciled.
> 
> I do agree in principle... however the internal logic of GnuCash dictates 
> that there is no such thing as "just reconciled items".
> 
> Consider a very busy bank account needing regular reconciliation... on 
> 15-january you try reconcile but you've written and recorded a check for 
> $53.50 on 20-december which is still not cleared. This $53.50 will remain 
> unreconciled ("outstanding") causing a discrepancy of $53.50 between your 
> 15-January bank statement, and your book. You reconcile, skipping the $53.50 
> amount, and all's well.
> 
> On 15-february the bank statement arrives, and the $53.50 check has cleared 
> on 19-january. The $53.50 status changes from (n)unreconciled to (c)cleared. 
> Additionally all intermediate transactions are cleared. Your 15-february bank 
> statement now matches your books.
> 
> According to my suggestions above logic the $53.50 will be counted in the 
> 'cleared' header, and be present in the reconciliation report. You will 
> afterwards then complete the reconciliation, which converts all 'c'leared to 
> 'y'reconciled.
> 
> If we were to follow your logic, and if we run the reconciliation report on 
> 15-february, and if we *aim* to look for the 'just-reconciled' items, we will 
> definitely miss the $53.50 transaction dated 20-December because it's now 
> reconciled/"archived". Remember the transactions do *NOT* have a 
> 'reconciliation date' so we cannot look for them using a simple query. Only 
> accounts have a last-reconciliation-date. We will *not* find them by querying 
> 'reconciliation-date minus 1 day'.
> 
> Logically you're not wrong but GnuCash internal logic will dictate the above 
> process must be followed.

Transactions don't have a reconciled date but splits do because it's splits 
that are reconciled.
xaccSplitGetReconcile gets the flag (n/c/y), xaccSplitGetDateReconciled gets 
the date it happened. 

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Further feedback

[Steve Butler]

Sorry for top posting.  Checked the transaction report items.  One is
Reconciled Date.   That date matches the bank statement date on which it
was reconciled.

How does that report get that date per transaction if the field doesn't
exist?

On Fri, Feb 8, 2019, 17:52 Christopher Lam  On 9/2/19 7:49 am, Stephen M. Butler wrote:
> > On 2/8/19 5:12 AM, Christopher Lam wrote:
> >> I've been experimenting and I think there's a logic error in your
> >> thinking -- *during* reconciliation, until it's complete, all
> >> 'reconciled' transactions are labelled 'cleared'. Reconciled
> >> transactions are, so to speak, gone and don't need to be shown on a
> >> reconciliation report.
> > The reconciliation report should run just after reconciliation has
> > finished.  Therefore, the just reconciled items will be marked as
> > reconciled.
>
> I do agree in principle... however the internal logic of GnuCash
> dictates that there is no such thing as "just reconciled items".
>
> Consider a very busy bank account needing regular reconciliation... on
> 15-january you try reconcile but you've written and recorded a check for
> $53.50 on 20-december which is still not cleared. This $53.50 will
> remain unreconciled ("outstanding") causing a discrepancy of $53.50
> between your 15-January bank statement, and your book. You reconcile,
> skipping the $53.50 amount, and all's well.
>
> On 15-february the bank statement arrives, and the $53.50 check has
> cleared on 19-january. The $53.50 status changes from (n)unreconciled to
> (c)cleared. Additionally all intermediate transactions are cleared. Your
> 15-february bank statement now matches your books.
>
> According to my suggestions above logic the $53.50 will be counted in
> the 'cleared' header, and be present in the reconciliation report. You
> will afterwards then complete the reconciliation, which converts all
> 'c'leared to 'y'reconciled.
>
> If we were to follow your logic, and if we run the reconciliation report
> on 15-february, and if we *aim* to look for the 'just-reconciled' items,
> we will definitely miss the $53.50 transaction dated 20-December because
> it's now reconciled/"archived". Remember the transactions do *NOT* have
> a 'reconciliation date' so we cannot look for them using a simple query.
> Only accounts have a last-reconciliation-date. We will *not* find them
> by querying 'reconciliation-date minus 1 day'.
>
> Logically you're not wrong but GnuCash internal logic will dictate the
> above process must be followed.
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Further feedback

[Christopher Lam]

On 9/2/19 7:49 am, Stephen M. Butler wrote:

On 2/8/19 5:12 AM, Christopher Lam wrote:

I've been experimenting and I think there's a logic error in your
thinking -- *during* reconciliation, until it's complete, all
'reconciled' transactions are labelled 'cleared'. Reconciled
transactions are, so to speak, gone and don't need to be shown on a
reconciliation report.

The reconciliation report should run just after reconciliation has
finished.  Therefore, the just reconciled items will be marked as
reconciled.


I do agree in principle... however the internal logic of GnuCash 
dictates that there is no such thing as "just reconciled items".


Consider a very busy bank account needing regular reconciliation... on 
15-january you try reconcile but you've written and recorded a check for 
$53.50 on 20-december which is still not cleared. This $53.50 will 
remain unreconciled ("outstanding") causing a discrepancy of $53.50 
between your 15-January bank statement, and your book. You reconcile, 
skipping the $53.50 amount, and all's well.


On 15-february the bank statement arrives, and the $53.50 check has 
cleared on 19-january. The $53.50 status changes from (n)unreconciled to 
(c)cleared. Additionally all intermediate transactions are cleared. Your 
15-february bank statement now matches your books.


According to my suggestions above logic the $53.50 will be counted in 
the 'cleared' header, and be present in the reconciliation report. You 
will afterwards then complete the reconciliation, which converts all 
'c'leared to 'y'reconciled.


If we were to follow your logic, and if we run the reconciliation report 
on 15-february, and if we *aim* to look for the 'just-reconciled' items, 
we will definitely miss the $53.50 transaction dated 20-December because 
it's now reconciled/"archived". Remember the transactions do *NOT* have 
a 'reconciliation date' so we cannot look for them using a simple query. 
Only accounts have a last-reconciliation-date. We will *not* find them 
by querying 'reconciliation-date minus 1 day'.


Logically you're not wrong but GnuCash internal logic will dictate the 
above process must be followed.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Further feedback

[Stephen M. Butler]

On 2/8/19 5:12 AM, Christopher Lam wrote:
>
> I've been experimenting and I think there's a logic error in your
> thinking -- *during* reconciliation, until it's complete, all
> 'reconciled' transactions are labelled 'cleared'. Reconciled
> transactions are, so to speak, gone and don't need to be shown on a
> reconciliation report.
>

The reconciliation report should run just after reconciliation has
finished.  Therefore, the just reconciled items will be marked as
reconciled. 

> My conclusion for the headers is:
>
>   * "starting-balance" - all *reconciled* on last-reconcile-date
>   * "reconciled-balance" - all *cleared* until today
>   * "ending-balance" - all *reconciled & cleared* until today
>   * "outstanding-balance" - all *unreconciled* until today
>

I think this is wrong.  At what point are you expecting the
reconciliation report to happen?

> Please refresh PR and go through the exercise again. I think this
> works better.
>
> On 8/2/19 1:58 pm, Stephen M. Butler wrote:
>> On 2/7/19 7:04 PM, Christopher Lam wrote:
>>> Unfortunately it's very difficult to understand the target report.
>>>
>>> It would be much better to have a tiny test datafile - 10 amounts per
>>> account, of various reconciliation states.
>>>
>>> I suggest a test datafile as follows:
>>>
>>> 1. BANK
>>>
>>>   * 01-jan-19 $1.00 reconciled
>>>   * 03-jan-19 $10.00 reconciled
>>>   * 05-jan-19 $100.00 reconciled
>>>   * 10-jan-19 $1,000.00 unreconciled
>>>   * 14-jan-19 $10,000.00 reconciled
>>>   * 18-jan-19 $100,000.00 cleared
>>>   * 15-mar-19 $1,000,000.00 unreconciled (future payment)
>>>   * Last reconciled date 15-jan-2019 - reconciliation amount was
>>> $10,111.00
>>>   * Today 8-feb-2019
>>>
>>> What should the reconciliation report header columns and contents look
>>> like?
>>>
>>> What would be the exact process for reconciliation (on the 15th Jan)
>>>
>>> How would the reconciliation report be useful for a user (report run
>>> today 8-feb-2019)
>>>
>> Let's start at ground zero.  There is $150,000.00 in the bank at the
>> start of the year (because we opened the account in early December) and
>> everything was reconciled to the 15-Dec-2018 bank statement (only the
>> deposit).
>>
>> We then make the above transactions on the dates noted and do a
>> reconciliation on 15-Jan-2019.  The standard GnC reconciliation shows a
>> beginning balance of $150,000.00 and a 15-Jan-2019 balance of
>> $138,889.00 but the electronic bank statement shows $139,889.00.  So, we
>> adjust the ending balance to show that and proceed with the
>> reconciliation.  Before doing anything on the screen we note a diff of
>> $10,111.00.  As we check off the first three and the fifth items, we
>> note the diff decreasing to $0.00.  At which point we finish the
>> reconciliation.
>>
>> We then run the Reconciliation Report and see.
>>
>> Reconciliation Report
>>
>> Account     Reconcile  Starting                 Ending                
>> Current
>>     Last Date  Balance     Reconciled   Balance    Outstanding
>> Balance
>>
>> Assets:Bank 01/15/2019 $150,000.00 $-10,111.00 $139,889.00 $-1,000.00  
>> $138,889.00
>>
>> Reconciled Transactions:
>>    Transaction Reconciled Amount
>>    Date  Date
>>
>>   * 01-jan-19   15-Jan-2019      $-1.00
>>   * 03-jan-19   15-Jan-2019     $-10.00
>>   * 05-jan-19   15-Jan-2019    $-100.00
>>   * 14-jan-19   15-Jan-2019 $-10,000.00
>>
>>     
>>     $-10,111.00
>>
>> Outstanding Transactions:
>>
>>   * 10-jan-19        $-1,000.00
>>
>>   -
>>  $-1,000.00
>>
>>
>> We note that the Starting Balance and Ending Balance agree with the Bank
>> statement and that the Current Balance agrees with our checkbook.
>> However, we get distracted by a family friend before we get a chance to
>> staple the report to the bank statement.
>>
>> Life moves on and we enter the other transactions noted above. On
>> 8-Feb-2019 we notice the bank statement still waiting to be filed but it
>> has no reconciliation report stapled to it. In a panic we open GnC and
>> run a Reconciliation Report (on the hopes that all we did was to forget
>> to attach the prior one). Low and behold it shows:
>>
>> Reconciliation Report
>> Account     Reconcile  Starting                 Ending                
>> Current
>>     Last Date  Balance     Reconciled   Balance    Outstanding
>> Balance
>>
>> Assets:Bank 01/15/2019 $150,000.00 $-10,111.00 $139,889.00 $-1,000.00  
>> $138,889.00
>>
>> Reconciled Transactions:
>>    Transaction Reconciled Amount
>>    Date  Date
>>
>>   * 01-jan-19   15-Jan-2019      $-1.00
>>   * 03-jan-19   15-Jan-2019     $-10.00
>>   * 05-jan-19   15-Jan-2019    $-100.00
>>   * 14-jan-19   15-Jan-2019 $-10,000.00
>>
>>     
>>     $-10,111.00
>>  Outstanding Transactions
>>
>>   * 10-jan-19        

Re: [GNC-dev] Further feedback

[Christopher Lam]

I've been experimenting and I think there's a logic error in your 
thinking -- *during* reconciliation, until it's complete, all 
'reconciled' transactions are labelled 'cleared'. Reconciled 
transactions are, so to speak, gone and don't need to be shown on a 
reconciliation report.


My conclusion for the headers is:

 * "starting-balance" - all *reconciled* on last-reconcile-date
 * "reconciled-balance" - all *cleared* until today
 * "ending-balance" - all *reconciled & cleared* until today
 * "outstanding-balance" - all *unreconciled* until today

Please refresh PR and go through the exercise again. I think this works 
better.


On 8/2/19 1:58 pm, Stephen M. Butler wrote:

On 2/7/19 7:04 PM, Christopher Lam wrote:

Unfortunately it's very difficult to understand the target report.

It would be much better to have a tiny test datafile - 10 amounts per
account, of various reconciliation states.

I suggest a test datafile as follows:

1. BANK

   * 01-jan-19 $1.00 reconciled
   * 03-jan-19 $10.00 reconciled
   * 05-jan-19 $100.00 reconciled
   * 10-jan-19 $1,000.00 unreconciled
   * 14-jan-19 $10,000.00 reconciled
   * 18-jan-19 $100,000.00 cleared
   * 15-mar-19 $1,000,000.00 unreconciled (future payment)
   * Last reconciled date 15-jan-2019 - reconciliation amount was
 $10,111.00
   * Today 8-feb-2019

What should the reconciliation report header columns and contents look
like?

What would be the exact process for reconciliation (on the 15th Jan)

How would the reconciliation report be useful for a user (report run
today 8-feb-2019)


Let's start at ground zero.  There is $150,000.00 in the bank at the
start of the year (because we opened the account in early December) and
everything was reconciled to the 15-Dec-2018 bank statement (only the
deposit).

We then make the above transactions on the dates noted and do a
reconciliation on 15-Jan-2019.  The standard GnC reconciliation shows a
beginning balance of $150,000.00 and a 15-Jan-2019 balance of
$138,889.00 but the electronic bank statement shows $139,889.00.  So, we
adjust the ending balance to show that and proceed with the
reconciliation.  Before doing anything on the screen we note a diff of
$10,111.00.  As we check off the first three and the fifth items, we
note the diff decreasing to $0.00.  At which point we finish the
reconciliation.

We then run the Reconciliation Report and see.

Reconciliation Report

Account     Reconcile  Starting                 Ending
Current
     Last Date  Balance     Reconciled   Balance    Outstanding
Balance

Assets:Bank 01/15/2019 $150,000.00 $-10,111.00 $139,889.00 $-1,000.00
$138,889.00

Reconciled Transactions:
    Transaction Reconciled Amount
    Date  Date

   * 01-jan-19   15-Jan-2019      $-1.00
   * 03-jan-19   15-Jan-2019     $-10.00
   * 05-jan-19   15-Jan-2019    $-100.00
   * 14-jan-19   15-Jan-2019 $-10,000.00

     
     $-10,111.00

Outstanding Transactions:

   * 10-jan-19        $-1,000.00

   -
  $-1,000.00


We note that the Starting Balance and Ending Balance agree with the Bank
statement and that the Current Balance agrees with our checkbook.
However, we get distracted by a family friend before we get a chance to
staple the report to the bank statement.

Life moves on and we enter the other transactions noted above. On
8-Feb-2019 we notice the bank statement still waiting to be filed but it
has no reconciliation report stapled to it. In a panic we open GnC and
run a Reconciliation Report (on the hopes that all we did was to forget
to attach the prior one). Low and behold it shows:

Reconciliation Report
Account     Reconcile  Starting                 Ending
Current
     Last Date  Balance     Reconciled   Balance    Outstanding
Balance

Assets:Bank 01/15/2019 $150,000.00 $-10,111.00 $139,889.00 $-1,000.00
$138,889.00

Reconciled Transactions:
    Transaction Reconciled Amount
    Date  Date

   * 01-jan-19   15-Jan-2019      $-1.00
   * 03-jan-19   15-Jan-2019     $-10.00
   * 05-jan-19   15-Jan-2019    $-100.00
   * 14-jan-19   15-Jan-2019 $-10,000.00

     
     $-10,111.00
  Outstanding Transactions

   * 10-jan-19        $-1,000.00
   * 18-jan-19  $-100,000.00
   * 15-mar-19            $-1,000,000.00

   -
  $-1,101,000.00

We quickly staple this to the Bank statement and file it away.  Then we
panic as there is no way we're raising $1,101,000.00 by 15-March!


And that is my user story for the evening (and I'm sticking with it)!


Note:  Personally I would have set the double amount flag so the Debit
and Credit columns would show.  And I would want the Debits totaled and
the Credits totaled.  I could verify that the Reconciled Amount = Debits
- Credits.  In the above story, they are 

Re: [GNC-dev] GnuCash 3 on Linux

[Chris Good]

-Original Message-
From: Geert Janssens  
Sent: Wednesday, 6 June 2018 12:10 AM
To: gnucash-devel@gnucash.org
Cc: Chris Good 
Subject: Re: [GNC-dev] GnuCash 3 on Linux

Op dinsdag 5 juni 2018 14:53:44 CEST schreef Chris Good:
> Hi,
> 
> I'm working on my BackupGnuCash stand-alone app.
> 
> I have 2 questions today:
> 
> 1.
> 
> I'm a little uncertain about where the saved reports and metadata 
> files are in GnuCash 3.0 for Linux.
> 
> I suspect they are by default:
> 
> ~/.local/share/gnucash/saved-reports-2.4
 2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a
saved-reports-2.4, but it will only save to saved-reports-2.8.
> 
> ~/.local/share/gnucash/books/[BOOK].gnucash.gcm
> 

Yes. Do note it can be [BOOK].gnucash_.gcm if you have several data
files named [BOOK]. And the gnucash part in that file name is only there if
the data file is called [BOOK].gnucash. Older versions of gnucash also
allowed to save to files without extension or with the .xac extension.
So it's really [BOOK-WITH-EXTENSION].gcm

> unless overridden by XDG_DATA_HOME.
> 
If you override XDG_DATA_HOME the files will be searched for and saved in
$XDG_DATA_HOME/gnucash/

However this can be overridden even with GNC_DATA_HOME. If that's set,
gnucash will search and save in $GNC_DATA_HOME (which may or may not end in
"/gnucash" unlike the XDG_DATA_HOME to which gnucash will always append
"/gnucash")

Regards,

Geert

Hi Geert,

Thanks very much for the above info.
I'm afraid it has been quite a while since these emails but hopefully now I
have a chance to follow up.

I was surprised to learn about the  part of
[BOOK-WITH-EXTENSION].gcm as I have never seen this.
I did some testing in Windows & Linux and I think I realise now how it
works.

There is a guid in both the main data file and the metadata .gcm files.
For example,
In main data file:
fe06ec827c69b29977e25a7c6c090229

In .gcm:
BookGuid=fe06ec827c69b29977e25a7c6c090229

So when the metadata is saved, GnuCash looks for (or creates)  a .gcm file
with a BookGuid matching book:id.

It seems that when you create a new book by using File, New, the
subsequently saved main data file has a new book guid created.
However, if you create a new book by either:
1) manually copying a main data file to a different directory and/or
filename
Or
2) using File, Save As 
there is no new book:id created so both books will continue to use the same
.gcm file.

I suspect there may be people who may like to have different settings for
different books but don't because they have created their new book by either
of the 1) or 2) methods above.

As the book:id guid only appears once in my main data file, I assume it may
be possible to correct this situation by:
a) save the main data file uncompressed
b) make a minor random(ish) change to the guid using a text editor (do NOT
change the length of the guid)
c) copy the old .gcm to a new .gcm (i.e. copy TEST.gnucash.gcm to
TEST.gnucash_2.gcm)
d) use a text editor to change the old guid to the new guid in the new .gcm

I'd like to document this in the wiki.
Can you please let me know if I have made any errors in my above assumptions
or forgotten anything important?

I think it would be useful if 2) above was changed so that a new book:id is
generated. Shall I raise a bug?

Regards,
Chris Good

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel