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