Created attachment 362587 [details] Resulting file after steps to reproduces followed When using the Close Book tool, the transactions on the closure date are not included anymore, leaving the income and expenses accounts with non-zero balances. Steps to reproduce (see attached file): On a new file with the default common accounts: 1) create a transaction in Expenses:Supplies on 2017-09-29 for the purchase of goods for 1,000 (credit to Cash in Wallet) 2) create a transaction in Expenses:Supplies on 2017-09-30 for the purchase of goods too, for 200 (credit to Cash in Wallet). The Expenses:Supplies now has a balance of 1,200. 3) use the Close Book tool with: - Closing date: 2017-09-30 - Income total: Equity:Opening Balances - Expenses total: Equity:Opening Balances - Description: Closing Entries Expected behavior: Expenses:Supplies has a balance of 0 Current behavior: Expenses:Supplies has a balance of 200 (the second transaction, on the date of closure, was ignored by the tool) Workaround: Run the Close Book tool using "date + 1", then manually edit the two closing transactions and move them back 1 day.
Created attachment 369806 [details] Before & After Close Book bug
Created attachment 369807 [details] After Close Book
I experienced the same issue. GnuCash 2.6.17 on Linux Mint 18.1 / Ubuntu 16.04 It appears that GC enters the closing TX as the FIRST TX on the Closing Date, instead of the LAST. Thus any other TX entered on the Closing Date are NOT Zeroed Out. My Before & After Files attached close_book_bug-JoTraGo-Before.gnucash & close_book_bug-JoTraGo-Closed.gnucash No Trace files generated
Thanks for the report. I can confirm the closing transaction sometimes doesn't take same date transactions into account. It depends a bit on the timezone of your computer. I have fixed this for GnuCash 3.4. The fix involves two changes: 1. transactions on the date of the closing are now also taken into account. Technically that means transactions are compared to the end-of-day of the closing date. 2. When displaying closing transactions in a register, closing transaction splits will by default be sorted *after* other splits on the same day. Note this will only apply to newly created closing transactions. You can easily recreate the older closing transactions though to fix this in the past as well.
