gnucash unstable: Multiple changes pushed

Geert Janssens gjanssens at code.gnucash.org
Sat Nov 18 11:47:27 EST 2017


Updated	 via  https://github.com/Gnucash/gnucash/commit/949f2db4 (commit)
	 via  https://github.com/Gnucash/gnucash/commit/cd9c3807 (commit)
	 via  https://github.com/Gnucash/gnucash/commit/ce900d1d (commit)
	 via  https://github.com/Gnucash/gnucash/commit/d66469fe (commit)
	 via  https://github.com/Gnucash/gnucash/commit/18dcbeef (commit)
	 via  https://github.com/Gnucash/gnucash/commit/aeb80a23 (commit)
	 via  https://github.com/Gnucash/gnucash/commit/0dfb921e (commit)
	 via  https://github.com/Gnucash/gnucash/commit/de4414b2 (commit)
	 via  https://github.com/Gnucash/gnucash/commit/954ce1ab (commit)
	from  https://github.com/Gnucash/gnucash/commit/61316648 (commit)



commit 949f2db4732283f6f8ac2e1b6cc1a960a3f8f311
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Wed Nov 15 14:30:25 2017 +0100

    Bug 778692 - Assign as payment should work for employee expense vouchers
    
    The way this is implemented is as follows
    - if gnucash can deduce a partner from the transaction that partner will be proposed
      this works for all transactions that are part of a business transaction already
      and will correctly detect pre-existing customer, vendor and employee payments
    - if no partner can be deduced gnucash will assume the transaction to be a vendor
      or customer payment based on the sign
    - in all cases the user can change the partner type in the payment window that's presented
      to any of customer, vendor or employee to correct gnucash' suggestion.

commit cd9c3807c03404f830104bd9726a061c6282fe88
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Sat Nov 18 17:42:46 2017 +0100

    Assign as payment - when random transaction is selected, reset transaction description to owner
    
    This will make the assigned payment more in line with traditionally created business payments

commit ce900d1df30d8767ed6f203998364b83687220b2
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Tue Nov 14 15:20:58 2017 +0100

    Assign as payment - refactor a few code blocks into separate functions
    
    And some tweaks to the message strings displayed in case of uncertainty

commit d66469fef8b49d038256f07a1642867ce65e200c
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Tue Nov 14 11:17:53 2017 +0100

    Assign as payment - Differentiate between new and existing payments for 'Assign as payment'
    
    When the selected transaction is already involved in a business payment,
    propose to Edit the payment instead of Assigning it as a payment.
    This is more informative and will help prevent users from accidentally replacing existing payments.

commit 18dcbeef8a9ba7213bdd14c7260c8b2d683a0168
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Tue Nov 14 13:56:56 2017 +0100

    Assign as payment - offer possible payment splits to user in case there are multiple valid candidates for assignment

commit aeb80a230e3cf0929c1251f110ad69bf81a13f74
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Thu Nov 9 22:56:52 2017 +0100

    Bug 734865 - Assign as Payment... can silently 'unpay' a payed invoice
    
    With this commit the 'assign as payment' logic now works as follows:
    - if the selected transaction is already linked to an existing payment, the payment dialog
      will present this payment again (same partner, post-to account, same selected document(s),
      same amount, memo, and transfer account).
    - if the selected transaction is not linked to an existing business transaction the logic
      will make a best guess as to whether the payment should be for a customer or vendor.
    - in both situations if the existing transaction has multiple splits that can be considered
      as transfer (or 'payment') splits the payment  dialog can't work with it (it can only deal
      with one transfer split). In this case the user will be informed that only one valid
      transfer split will be retained and the others ignored.
    - the other thing the payment dialog can't handle are APAR type splits that are not associated
      to a lot at all. In case of transactions not part of a business transaction they will be
      silently ignored on the assumptions these were manually entered transactions with the intention
      to be linked to business transactions. On the other hand if such a split is part of a transaction
      that is also linked to a business payment already, a warning will be issued these splits will
      be removed from the new payment.

commit 0dfb921e86357df280ded13c7cd1ce9da139f8c4
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Mon Nov 13 19:15:04 2017 +0100

    Add functions to retrieve a copy of splits of a certain type from business transactions

commit de4414b2a100812aa796041d1a87c99d1aa63418
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Thu Nov 9 20:36:54 2017 +0100

    Inform the user when assign as payment can't be used

commit 954ce1ab118850ec8d8f844698407b697829359a
Author: Geert Janssens <geert at kobaltwit.be>
Date:   Tue Nov 14 14:00:04 2017 +0100

    Mark unused function parameters as such in dialog-payment.c



Summary of changes:
 gnucash/gnome/dialog-payment.c                | 777 ++++++++++++++++++++------
 gnucash/gnome/dialog-payment.h                |   2 +-
 gnucash/gnome/gnc-plugin-business.c           |  36 +-
 gnucash/gnome/gnc-plugin-business.h           |   4 +
 gnucash/gnome/gnc-plugin-page-register.c      |  19 +-
 gnucash/gnome/gnc-plugin-page-register.h      |  10 +
 gnucash/gnome/gtkbuilder/dialog-payment.glade |  47 +-
 gnucash/gnome/ui/gnc-plugin-business-ui.xml   |   6 +-
 libgnucash/engine/Transaction.c               |  63 ++-
 libgnucash/engine/Transaction.h               |  20 +-
 libgnucash/engine/gncOwner.c                  |   4 +-
 11 files changed, 793 insertions(+), 195 deletions(-)



More information about the gnucash-patches mailing list