When editing an unequal split, load the entered # of shares or %
The main problem we've been encountering is that the editing of expenses is a bit annoying. We usually split the costs unequally and in parts (when someone brings over a friend or when a plate is eaten during several meals), but when we want to edit the number of parts (to add someone who ate later or simply to correct a mistake), only the amount to be paid by each person is remembered by the website and the number of parts everyone had seems to be forgotten by the app, although that was the input that it became at the begining (when switching to the unequally / parts button, everything is set back on 1 part for everyone in the group again).
It's such a small thing that it seems to be rather a bug than a new feature needed. Still, it would significantly improve our experience.
Updating our response since it’s been a long time since the idea was opened. Even though saving the type of unequal split feels like something that would obviously be nice to have (I certainly would use it myself every so often), it requires a change to our data structures, and is therefore a bunch of difficult work to fix, especially since it would need to be fixed separately across iPhone, Android, and web.
If you have a specific use case where not having this feature is really bothering you a lot, please email email@example.com, or comment below to let us know why it’s important to you. The original poster’s meal example is clear and I’m wondering if there are other reasons why it is needed, or any easier way for us to fix it.
In terms of the priorities of our small team, most bills on Splitwise are split equally, so we haven’t been able to make this a priority. We’re not likely to roadmap this feature unless we see a big groundswell of support from the community.
Thanks for your patience and sorry that this has been open so long. We also have some ideas for work-arounds, so feel free to email support if you are stuck with a particular situation.
When I split a bill unequally with the percentage option and save it, it will convert the unequal amounts to absolute values. So whenever I edit this bill, the amounts stored will of course not add up to the changed value. So I have to manually calculate the percentage myself and enter them again in the changed bill...
For me this problem is also the most important problem to choose if I will be using splitwise again or not. We are a large group to go on a weekend, and it is never possible to know exactly who will stay 1 or 2 nights, who will eat, if the families bring all of their kids or one less, ... so many reasons to make changes to the division of the parts after you filled in at first time. I can imangine you suggest to fill in later when we know definitly, but then we have to keep everything on another way. Now we filled in all costs in advance (after we went shopping and got the bill of the house), so we only needed to make little changes on the amount of people who are there for meals and overnights. But that seemed to be not possible. For me this is an important lack.
This was a problem on our latest group trip. When I had to adjust the total bill, I had to figure out what what the initial share split. Eventually I learned to annotate the share split in the notes of the bill in case the bill needed further changes.
'Remembering' the share-split in the bill, would be a great feature.
This is not an idea but what seems like a small bug.
When dividing an expense in a group by shares (i.e. one person has 1 share, the other 3, etc.), the expense amount cannot be updated. In other words, when I try to update an expense which is divided by shares, I get the following error message:
"The following errors occurred:
- The total of everyone's owed shares ($XX.XX) is different than the total cost ($YY.YY)"
I hope this is clear :)
Manideep Gvns commented
When I add unequal splits in the payment and when my friend changes it to equal splits, give an option to revert his changes back so that the old split comes into picture again..
It's just like giving undelete option whenever someone deletes a bill.. Give revert changes option just like you gave undelete option..
Jens Timmerman commented
You don’t need to store this information. You can recompute it
On the fly when you do an edit?
This is what the human making the input has to do anyway
I just don't understand why this is still open for so long.
It is absolutely nothing to do with your data structure, I am 100% sure because it is to do with UI/UX fix. This fix would just need <100 lines of code. In the UI, while switch "split by.." tabs, first time user already split it by share, ok, so this UI needs to remember this, and when I switch tag to "split by amount", then the amount should be calculated based on the previous select on "split by shares", and same with "split by %.. and other options". That's it, no rocket science here. The very clear bug here is, the developer just resetting the "split by shares" to "1" by default whenever I switch to its tab, a blunt direct error!!
We travel with friends and their children. For general expenses (like a house) we will count each adult as a share and each kid as a half share. We will also count adults with a couch as a half share vs one with a bed. It's ok to break it out by person since we can add the kids who don't have email addresses now, but when it comes time to settle by family, we still have to add together the members of the family. it would be good if you could link the members and identify them as "x family" and then someone could settle the family. Also, when putting the shares in for an expense, when you go back in, it shows the amount and not the shares. If you click on the shares button it shows everyone as 1 share instead of what was entered (like .5). It makes you unsure that the shares were entered correctly.
For what it's worth, I agree that this is an annoyance. I am splitting a rental house based on how long each person is staying at the house. While planning, some people agree to 3 nights, but later change to 5 nights. When I edit the split, I have to re-enter all 14 people's shares just to make this one change.
Or, a husband wants to pay for his wife. Rather than updating her share to zero and his to add 3 more, I have found it simpler to stay in the "split unequally" view and zero out her bill and adjust his for the difference.
Maybe this use case will help you all see the value of this feature.
Basically i have found that the simplest way to split a bill with a percentage of service charge followed by a percentage discount is by adding the amount exactly as shares, with each share being 1 cent. Hence, it is likely that 4 numerals is needed as each persons share will be likely to be from 1000(i.e. $10) to 9999 ($99.99).
However as currently the app only shows 1 numeral, it is difficult to see the entire value added. Also, it would help if the number "1" share was not input by default, as it would mean i need to delete that number before adding the exact share amount i need
I hope it's not pointless to reply to this rather old ticket, but for what it's worth, I don't think that this requires you to change your existing data structures.
I assume that currently, you only store the effective values that resulted from the split method that was used when saving a bill and discard the actual method and its parameters.
What if you enhanced the edit dialog (purely in the frontend!) to compute the individual split method parameters from the stored effective values? Apart from the itemized bill, there should be a unique or at least a minimal solution for all available split methods.
The only issue I could think about is possible rounding errors, but that should be solvable, too.
Brad Bice commented
I agree, I think in other words I would like to assign a particular split type to a friend. For example, my wife and I split everything based on a percentage. So every expense we enter we would want to split in the same manner (60/40, for example.) I'd like to be able to edit a friend (in this case my wife) and tell Splitwise that any expenses shared with her will default to a percentage with those values.