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 support@splitwise.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.
Best,
Jon
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 support@splitwise.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…
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.
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.