inversion of sign in splits causes the transaction to not be savable

[Andrei Kucharavy]

Previously, Homebank used to issue a warning upon sign inversion and when the sum of the categories in the split was not equal to the category.

It seems that since 5.4, those warnings became blocking errors.

In other words, it is not possible anymore to clone a transaction, then go through categories in the split, inverting signs and modifying amount in order to obtain a final sum that can be saved.

This feature is critical in order to perform an expenses splits within household.

Example:

If I go and do grocery shopping that includes common cleaning goods, common pasta and an energy bar for myself, previously I could enter the "expense for the grocery expense", split it into sub-categories, save it, clone it, modify the account and type of operation and then go through the splits, adjusting the amounts and inverting the signs (aka what others owe me).

Now, the same operation requires me to manually calculate the splits for the sub-categories, their sum, enter it as a new income, re-enter all the categories with the splits and only then I can resume.

This mode of operation is extremely laborious and is inconsistent with how HomeBank operated previously.

System information:
HomeBank 5.4.2 under Windows 10, version 1909; GTK+ 3.24.14

Dialog location:
Inherit Transaction > Transaction Splits > OK greyed out

Steps to reproduce:
Add an expense transaction with splits, save, clone, modify splits so that the sum is positive.

Expected results:
Upon clicking OK, the splits are summed and the total amount in the main transaction entry screen is modified to be positive.

Actual results:
OK is greyed out and is impossible to click

[Maxime DOYEN (mdoyen)]

ok, I have changed this.

question: is a button to invert the sign of every split lines is useful in your use case ?

[Andrei Kucharavy (andrei-chiffa136)]

Thanks, that's awesome!

As for the button - not necessarily - the color-coding (red for negative vs green for positive) is pretty much enough.