Split bill by amount or percentage.

[Evidlo]

Certain applications like Kittysplit and GroupTabs allow for splitting a bill unequally. This is useful in situations like a restaurant where one person may pay for multiple people's meals.

This can be emulated by separate bills for each check, but really the bills should be grouped together logically and the alternative is tedious.

[almet]

Hi, thanks for opening a discussion here !

Do you have a copy of the UX these projects use to accomplish this?

[Evidlo]

Kittysplit UI:

iou.ch UI:

[almet]

Okay, thanks for the info. I wonder if we want to do this, I fear it will clutter a bit the UI. What do other involved contributors think ? (cc @eMerzh @0livd @JocelynDelalande)

[almet]

and @Glandos, of course!

[eMerzh]

I would clearly not do this by default (like not in the main path...) But maybe behind an advance option or smth....

[JocelynDelalande]

UI-wise : for that king of needs, on the add bill popup, we could have two tabs :

• « simple » with what we have now
• « advanced » with the kind of new stuff we are discussion, for example.

note: it would have to play nice with user weights.

The impact on db would be quite important also.

[almet]

The impact on db would be quite important also.

For me, this is one of the main aspects we should consider. Supporting this scenario means that the API will change quite a bit, and I'm a bit reluctant to this.

Also, UI-wise, IHM always has been as simple as can be, and I believe it's the wise path. Any other input would be useful :-)

[almet]

I'm mostly leaning towards the "we should not go that way", because it seems to be a complex use case that I'm not sure will be useful to the vast majority of users.

So unless we have other inputs, I'm thinking about rejecting the idea.

[almet]

Closing as a wontfix. Feel free to re-open if you want to discuss further.

[vigiraud]

I'm surprised this is considered a complex and rare use case. In my experience, the vast majority of expenses need to be split in a personalized way. The lack of this feature in open source/free solutions is why some people (including me) are stuck with Tricount. I strongly encourage to consider this feature.

[Natim]

@2lafru To be honest, I had the use case a couple days ago where we had to split a restaurant bill and one person haven't had drinks.

The way I did it was to create two bills:

• 1 bill paid by the person with the amount for the 1 person
• 1 bill with the rest of the amount paid by the same person with the amount share between the remaining people.

I think we could have a wizard that allow to create a split bills with custom amount per people and then create multiple bills accordingly, those we could keep the API simple and handle this use case for some people.

[almet]

I'm surprised this is considered a complex and rare use case

It's my experience : I've been using the app since its conception and i never did miss this feature, so considering this as an "urgent" use case or something that we should "absolutely" doesn't seem right.

That being said, allowing this use case via a different UI might be acceptable. We should take extra care about not making the UX more complex that it already is.

[jimbo2106]

I plan on implementing this feature. The first step is to refactor the code so that the api can diverge. Please approve pull request: https://github.com/spiral-project/ihatemoney/pull/533

[Glandos]

The first step is to refactor the code so that the api can diverge.

I am really curious on this :)

[jimbo2106]

@Glandos @almet @Natim @2lafru Getting closer to having this feature implemented. In the project settings you'll be able to set "advanced weighting" to enabled. The front end gui is working and additional database queries have been added. I'm having issues with retrieving the data (weights) from the submitted form. My attempts at using FieldList(FormField(ForWhomForm) for the "For Whom?" section haven't been successful.

If you guys would like to make an attempt the tree I'm working on is here: https://github.com/DavidRThrashJr/ihatemoney/tree/split_bills

New additional weight fields in the add bill screen. Amount due changes dynamically, when the weights are changed.

Settings screen:

[Glandos]

@DavidRThrashJr I have created a demo project with 2 participants and 1 bill. Then switch to your branch, and I got this:

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such column: billowers_1.ower_id
[SQL: SELECT person.id AS person_id, person.project_id AS person_project_id, person.name AS person_name, person.weight AS person_weight, person.activated AS person_activated, anon_1.bill_id AS anon_1_bill_id 
FROM (SELECT bill.id AS bill_id 
FROM bill JOIN person ON person.id = bill.payer_id JOIN project ON project.id = person.project_id 
WHERE bill.payer_id = person.id AND person.project_id = project.id AND project.id = ? ORDER BY bill.date DESC, bill.creation_date DESC, bill.id DESC
 LIMIT ? OFFSET ?) AS anon_1 JOIN billowers AS billowers_1 ON anon_1.bill_id = billowers_1.bill_id JOIN person ON person.id = billowers_1.ower_id ORDER BY anon_1.bill_id]
[parameters: ('demo', 100, 0)]
(Background on this error at: http://sqlalche.me/e/e3q8)

I don't know how you managed to reach your screenshot.

[jimbo2106]

@Glandos Try again with my latest commit.

[rom1dep]

Hi, as I was looking for a self-hosted tricount alternative, I found out about this project,

not being able to distribute a bill unevenly almost ruled it out for me (and luckily I dug up this issue).

UI doesn't have to be sacrificed either, here is how it looks in tricount, which is pretty much what @JocelynDelalande proposes.

Thanks @DavidRThrashJr for pushing this :)

[indatwood]

That's great :-) @DavidRThrashJr I've checked out your latests commits, but didn't manage to reach a usable state either.

Here is what I have currently

@DavidRThrashJr are you okay opening a pull request here indicating "WIP" in its title, so we can follow your progress? Cheers!

[Glandos]

The UI is not the only thing, but clearly, the Tricount design shows that it is easier for a user to enter an amount instead of a weight.

[jimbo2106]

@Glandos The weights just need to equal the amount, if you want to enter direct amounts.

@indatwood you have to go to the project settings to enable the advanced amounts We may implement it like triccount eventually

[jimbo2106]

I've copied the triccount layout, except you can't specify the amount per person in the due column. You have to use the weight column.

The advanced toggle switch is enabled for all projects. You can set the project to be in the advanced mode by default, for those who always use the advanced mode it saves a button press.

Please note that currently, you can specify the weights for each person at the project level.

It doesn't make sense to have weights at the project level and the bill level.

My proposal is to allow users to still be able to set the weights for each person at the project level. What will happen is, if the weights for each person at the project level is not set to 1 (default). Then when creating a new bill, the form will automatically populate with the weights that are set at the project level.

@Glandos @indatwood @almet What do you guys think?

[Glandos]

My proposal is to allow users to still be able to set the weights for each person at the project level. What will happen is, if the weights for each person at the project level is not set to 1 (default). Then when creating a new bill, the form will automatically populate with the weights that are set at the project level.

I'm currently using weights for a full project, so I'll be glad if it's still working. What I don't understand here is: what happens if weights are changed when creating a bill? Will it change weights on the project?

[jimbo2106]

I'm currently using weights for a full project, so I'll be glad if it's still working.

There wouldn't be a clean transition to what I proposed. The function to calculate what is owed won't use the project level weights anymore. Only the weights on the bill level will be used to calculate what is owed. I could write a transition script to set the bill level to be what is set at the project level during the upgrade to the new version.

What I don't understand here is: what happens if weights are changed when creating a bill? Will it change weights on the project?

No it would not change those weights. If the user wants to modify the "default" weight they would have to go back to the project level settings and modify the setting there.

The easiest solution would be to only have the advanced toggle switch show up if the user wants the advanced mode. Basically you get one or the other you can't have both project level weights and bill level weights.

[indatwood]

Thanks for working on this :-)

At first, I found it weird to use weights rather than direct amounts, but I now understand this is due to the naming. Especially if we are using weights on the project, then I think we shouldn't name the two concepts the same way.

What about percentage? I think it betters explains what it does. Also, would it be complicated to add the direct amounts?

[rom1dep]

There wouldn't be a clean transition to what I proposed.

@DavidRThrashJr Both weighting mechanisms could be used in combination to ease the transition, I think it's fine as long as it's clear what the effect is:

user	weight¹	user weight²³	effective weight³	due
persona	300	2	600	362
personb	156	1	156	94

¹ editable in the bill form ² read-only in the bill form, editable in project conf ³ only shown when per-user weights are used

I even think it's even preferable like this, because the calculations are everywhere consistent (and not dependent on set preferences).

[rom1dep]

@indatwood : what do you do with/how do you name "percentages" whose sum isn't bound to equal 100?

[jimbo2106]

Both weighting mechanisms could be used in combination to ease the transition, I think it's fine as long as it's clear what the effect is:

Too complicated, this didn't pass the "wife usability check"

I'm ok, with making the advanced mode unavailable for people who want to use the weighting on the project level. I just need confirmation from the maintainers of this repo that they'll approve a merge request if it is designed this way.

[rom1dep]

@DavidRThrashJr if both approaches can't play together/at the same time, doesn't it also mean giving up on backwards compatibility for existing projects?

[jimbo2106]

Correct. The best case scenario for the existing projects is as follows: When we run the migration.py to the new database schema that includes the weight column in the billowers table, we set the weight in that table to the current project level weights. After that point, the add bill form will pre-populate with the project level weights, thus allowing both project level weights and bill level weights to co-exist.

[indatwood]

@indatwood : what do you do with/how do you name "percentages" whose sum isn't bound to equal 100?

If it's percentages, then their sum should be equal to 100%, for sure!

In term of UX, we could have a range input for each person which participates and have the sliders assigned automatically. For instance if there are two people, then setting the first slider will automatically assign the second one; if there are three people, then assigning the first two will assign the last one.

Or we could use a slider with more than two handles ! see https://refreshless.com/nouislider/slider-values/

[Glandos]

OK, I will throw another opinion here. I agree that mixing weights between project and bills is too complicated. We are not an accounting software.

I propose the following:

• Keep project weights, to be able to use them as templates for bill weights
• Fill the new bill form with project weights
• In an advanced section, show weights, but the only editable field should be the amount, not the weight. The main use case is that participants paid something different for each other, and amounts are known, not weight.

Javascript will be needed to assist the user: update weight when amount change and ensure that the total is correct.

I also feel not so comfortable with weights. Weights are good at project level, but for bills, it should be really easier to show percentage.

[jimbo2106]

• Keep project weights, to be able to use them as templates for bill weights

• Fill the new bill form with project weights Javascript will be needed to assist the user: update weight when amount change and ensure that the total is correct. I also feel not so comfortable with weights.

Thanks for the feedback, I've implemented the above recommendations in the last commit. For the weights column when creating a bill I've removed the mention of weights, so that users can use that field however they want. This could be percentages, i.e. 60/40 or specific amounts 20/10 for a bill of 30. This is exactly how ttaccount handles this, they don't label the field.

You can test and use the demo project I have hosted here:

http://23.95.228.117:5000/

If we go this route, a migration script has to be made moving whatever is in the project level weights into the newly created weight column in the billowers table. Would someone else be willing to take a stab at this? I need to start developing api v2.

[JocelynDelalande]

Thanks @DavidRThrashJr ; this is an hard design exercise.

Just tested quickly, a few remarks :

why advanced mode is enabled by default ?

bill weights vs bill ammount stuff

For the weights column when creating a bill I've removed the mention of weights, so that users can use that field however they want. This could be percentages, i.e. 60/40 or specific amounts 20/10 for a bill of 30. This is exactly how ttaccount handles this, they don't label the field.

That is a very mathematics approach, hard to understand for end-user.

I think we have to implement @Glandos suggestion : fully showing in UI, that amounts are expected. Manually using weights at bill-level stuff should be IMHO an extra-feature, to be added as a separate feature/UI.

In backend, it could remain handled as weights : it will ease to expose that bill-level-weight as-is as another mode later, and helps answering the « what happens when the bill amount is updated ».

using person weights as template rather than variable kills original weights use case

When changing a person weight, the fact it does not impact the whole project but rather become a default kills my whole usecase for person-level weights

I explain : I spend a couple of days with a group. The group is not stable : we shop and cook and share meals together. But not everyone attend to every meal. At the end of those days, to account how many meals each person owe, we set weights afterwards, with the final meals counts.

I implemented the weights feature for that exact use case, and I might not be the only person using it that way, so I will be very careful that it do not gets unusable :-.

One approach could be, for person weights :

• do not label the field « default weight » but stick on « weight », at least if there is no bill with weights overriden at bill-level
• when changing person weight, prompt the user if he wants to update existing bills, adding an extra-warning if there are already some bills with bill-level override of weights

Maybe to ease tracking of bills with overriden split, we could keep a share overriden boolean somewhere. It has two interests :

• easy tracking of bills with overriden split
• faster computation for the vast majority of bills

What is the URL stuff ?

It seems not any related with bill splittig.

[zorun]

@DavidRThrashJr I think I found a bug with http://23.95.228.117:5000/demo , or there is something I don't understand:

• at the beginning, there are no bills
• I start adding a bill with amount 42, paid by foo
• in the same form, I change the "weight" of bar to 20 and foo to 1. The JS correctly displays "Due 40" for bar and "Due 2" for foo
• I save the bill
• now bar owes foo 280, as shown on both the sidebar and the "Settle" tab!

I think this complements Jocelyn's analysis that the original "weight" feature has a different semantic than this proposed feature, and mixing the two concepts may be really confusing.

[jimbo2106]

I think I found a bug with http://23.95.228.117:5000/demo @zorun definitely a bug. I enabled "Advanced Weighting Enabled by Default?" and now it shows it in the summary correctly: +40 for foo -40 for bar . Will fix it soon.

One approach could be, for person weights :

* do not label the field « default weight » but stick on « weight », at least if there is no bill with weights overriden at bill-level

* when changing person weight, prompt the user if he wants to update existing bills, adding an extra-warning if there are already some bills with bill-level override of weights

@JocelynDelalande thanks for going into your use-case. I think this is a good way of handling the issue.

why advanced mode is enabled by default ?

Saves you an extra button click, if you use the advanced mode a lot. I don't care if we take it out, but it's just a small setting for the project.

bill weights vs bill ammount stuff

That is a very mathematics approach, hard to understand for end-user.

I'm going to stand my ground on this one as it passed the "wife usability check" ;) In addition, this is the way triccount does it and it is a very popular app, it's rated 5 stars with 37k votes on the play store.

On another note, do you guys mind if I remove the "For whom?" label on the bill creation screen. It's not mobile friendly, while in "advanced mode". As in the Due column doesn't fit on screen.

[indatwood]

Thanks for your work on this!

I'm sorry to jump on this, but "wife usability test", seems inappropriate to me : we don't know your wife nor her experience with computers, and it seems to rely on the false premise that "women are bad at tech".

On the topic, I think we should decide together what the ux should be here if possible.

My stake on this is I that using amounts seem to cover better the use case I have in mind : we went to the restaurant, and we split things unevenly. We have the bill so we know what the amounts are.

Why not using weights for this but, what's your use case?

[jimbo2106]

I'm sorry to jump on this, but "wife usability test", seems inappropriate to me : we don't know your wife nor her experience with computers, and it seems to rely on the false premise that "women are bad at tech".

Not what I meant. She's my most important customer, so her opinions have an impact on the product.

My stake on this is I that using amounts seem to cover better the use case I have in mind : we went to the restaurant, and we split things unevenly. We have the bill so we know what the amounts are.

The way I have it now, this use case and others can be satisfied.

A use case that involves percentages is: You have an agreed upon percentage for your living expenses. I.e. rent / car expenses are split between individuals at different percentage weights.

[Glandos]

bill weights vs bill ammount stuff

In the current demo, we can only set weight, and it updates amount. Wouldn't it be possible to have the other way: set amount and it updates weight? It would make a lot of JS, ensuring that everything is consistent, but it can cover all use cases I guess.

[zorun]

Actually, with the current demo, you are free to put an amount in the (unlabeled) "weight" field. It's just a bit weird because the "Due" column becomes useless for this use-case.

[MagicFab]

I am new to the project, I just finished the Spanish translation. I like the "keep it simple" approach.

I tried the demo server and it looks good. I'd like to suggest automatically adjusting the remaining amount when the first weight is changed in an bill.

For example, there is a 2000$/month fill for rental, in a 5 member project

I assign 1000 weight to the first member. The other 4 members would be adjusted to 250 equally. This would ensure the bill is fully accounted for.

Does this make sense ? Should it be a manual option/button ("mainly paid by..") ?

[MagicFab]

I found a few missing pieces when testing this at http://23.95.228.117:5000 <- invitation link to my test project :

• In the summary report the "How much ?" column still indicates an amount split in 2 (50%) when I input 700/500 weights.
• When editing a bill with varying weights, only the weight can be edited, the due amount is not shown
• When editing a bill the total amount only show one decimal for integer values
• The owed amount seems broken in the left column. For a 1200$ bill for 2 people, with 700/500 weight, it shows each owing 420000 - see here.

[jimbo2106]

I tried the demo server and it looks good. I'd like to suggest automatically adjusting the remaining amount when the first weight is changed in an bill.

This could be something we could add later, but let's get the main functionality merged first.

* In the summary report the "How much ?" column still indicates an amount split in 2 (50%) when I input 700/500 weights.

Yes, I was delaying the decision on how to handle this. Should we just hide the split amounts? Or replace it with "Custom Allocation"?

When editing a bill the total amount only show one decimal for integer values

Two decimals will show if it's non-zero. i.e. 123.45

* The owed amount seems broken in the left column. For a 1200$ bill for 2 people, with 700/500 weight, it shows each owing 420000

Yeah sorry this bug is know still need to fix it. If you enable "advanced" mode in the project settings it shows the correct amount.

[MagicFab]

Yes, I was delaying the decision on how to handle this. Should we just hide the split amounts? Or replace it with "Custom Allocation"?

I am not sure what you mean here. I think it should behave the same as when first entering a new bill, I was expecting that.

Two decimals will show if it's non-zero. i.e. 123.45

If it's currency, I would expect to always see 2 decimals and the appropriate symbol ($, euro, etc.). Otherwise it doesn't feel consistent and can lead to think it's accepted in the project, lowering trust in its accuracy.

[thoelze1]

I have just found this project and am considering using it for sharing expenses among a household. We'd rather not use Splitwise but I like that it offers 5 ways of splitting a bill:

• By an even split. Each participant owes the same amount.
• By percentages. The user assigns each participant a percentage such that their sum is 100%. Each person's percentage is multiplied by the bill to determine what that person owes.
• By shares. The user assigns each participant a positive number of shares. A participant then owes a percentage of the total bill equal to the percentage of shares they hold.
• By adjusting an even split. The user assigns at least one participant to be solely responsible for a certain amount of the bill, and the rest is split evenly across all participants.
• By exact amounts. If none of the other breakdowns fit, the bill can be broken up into exact amounts.

To me, each of these methods is quite intuitive and I can imagine real world scenarios where I would use them. In my mind , each would be easy to implement in terms of another one with "exact amounts" being the parent of this tree of implementations. In any case, the logic isn't complicated. I haven't had a chance to look at the API yet, but once I do I will see what I can contribute and if it falls in line with the maintainers' vision for the UX.

From a quick read of this thread, I'm not sure what is meant by "weights". If this is the same behavior as shares, then it is very important to me, probably the most important use case other than an equal split.

[hiqua]

@jimbo2106 did you give up on your changes? Should we start from scratch?

For reference, this is how it looks like with a recent version of Tricount. One can set fixed amounts, and the rest is split between the others with the coefficients given. I rarely use fixed amounts, but the coefficients are quite useful.

Tricount screenshot


[jimbo2106]

I personally am using Tricount.

We never came to consensus on how to move forward. The project level weights are contentious with the bill level weights. @Glandos is the maintainer, so he has the ultimate say and I'm not willing to maintain a fork. This is still my opinion: https://github.com/spiral-project/ihatemoney/issues/471#issuecomment-617174166

My fork still works if you'd like to try it out. @hiqua

https://github.com/jimbo2106/ihatemoney

[almet]

Hi, if you want to have this merged here, (and that would be great), then you need to be open to discussion with the team who will be maintaining the project in the long term.

My understanding is that we should input amounts here rather than weights, or at least make it possible to have both and have something easy to use. cf what @Glandos said :

In the current demo, we can only set weight, and it updates amount. Wouldn't it be possible to have the other way: set amount and it updates weight? It would make a lot of JS, ensuring that everything is consistent, but it can cover all use cases I guess.

Could you please recap what is blocking this to be merged? Thanks :-)

[azmeuk]

For the record, here is how this is made on ze-coloc.fr:

The UI let the users choose between weights or absolute money amounts:

[azmeuk]

I am interested to help with this feature, this is dearly wanted at home :) To make echo to the past discussion, we are 6, including 3 people totally uncomfortable with tech.

I also feel not so comfortable with weights. Weights are good at project level, but for bills, it should be really easier to show percentage.

My 2 cents: this really depends on the situation but there are examples where percentages are hard to compute and don't really make sense.

For instance, 6 people go in vacation together during a week and they rent a house. They all come and go at different times. They want to split the bills by the number of days passed in the house. With percentage it is not obvious at all, with weights you just assign the number of days to people. The usecase I encounter the most is food bills repartitions for roomates : with weights you just have to count the number of meals were people were present. To that regard I find the comment of @ thoelze1 pertinent, I think I can tell real-life examples I encountered for almost all of those.

Could you please recap what is blocking this to be merged? Thanks :-)

I am interested in reopening the discussion before spending time in the code. Sadly Jimbo's branch is too outdated now to be testable out-of-the-box but at least the code is still there. @glandos would you have a bit of time to talk about this and summarize your thoughts :pray:? Maybe we can open a new ticket too to clean all the history.