Split a project by year / archive old bills

[zorun]

I have used the same project for 5 years, and it is now too big to be usable: it has 1200 bills and it's all really slow (both for the server and for the browser). I had already improved IHateMoney's performance when I was having performance issues with "just" 350 bills (#161) but it's no longer enough. And now I understand that small projects fit better in the philosophy of IHateMoney.

A nice way to solve this situation would be to "split" a project by year: given a (big) project, create many smaller projects by grouping bills by year. That is, from a project named myproject, it would create:

• myproject-2015
• myproject-2017
• myproject-2018
• etc

This way, the project for the current year would become much smaller.

It could also be seen as a way to archive old bills, so that you only keep bills for the current year in the main project.

Another use-case is to set different weights to participants depending on the year: at the end of 2019, you could "archive" all bills from 2019 in a separate project, and then decide which weights should be applied to 2019 (for instance based on your total income of the year). You would then settle the 2019 project based on these weights, and import it as an initial debt in the 2020 project.

In any case, I'm not sure it's a very common situation, so I'll leave this ticket open to see if somebody else has the same needs.

[zorun]

I have a quick & dirty implementation of splitting by year, implemented as a command in manage.py. I will publish it at some point.

[Glandos]

I use the same project to balance bills in my house. But once in a while, we do the math and money transfer, and clear everything. Accounting history is done in another software, so my project is never big enough.

Don't you think pagination (#480) can improve this?

[almet]

Hi, I missed this, but I believe I have a similar use case here. We index our expanses on our income, and the income fluctuates during the year. We created multiple projects and reset our weights, but I feel that this should be better.

One way to solve this would be to attach the weight of the persons in the bills.
For your use case of having too many bills, I think that the recent pagination feature should do the trick, no?

[zorun]

Now the main issue for me is really to have different weight for each year, exactly like you (based on average income for the year).

Pagination does help for performance (this is why I developed it ;) ), but the "Statistics" page still takes 15 seconds to load with 1200 bills.

I ended up splitting the history of bills by year (using the quick & dirty command I was mentioning above). And now, we just create a new project every year.

[zorun]

To be more accurate: we add bills during the year, and then, at the end of the year (or even a bit later), we change the weights of the participants according to their average income during the year. Then we settle this year, and we start a new project for the following year. And so on.

This works very nicely, and it would be much more difficult to do with per-bill weights (which I think would be too complex anyway)

[almet]

What I had in mind is :

1. When needed, you change the weights of the members ;
2. When you enter a new bill, it uses the last defined weight of the members at this time ;
3. It stores the information of the weights inside the new bill.

It means that the weights can't be changed (or manually, which opens a lot of UX issues I think :/) but it might work for me. Or we could do things differently by having a way to select multiple bills and apply a weight on theses.

But… I'm not a fan of these solutions because it makes things more complex than needed :/

———

I like how you're doing this. I might also do this :-) We might want to have a way to group sub-projects so it's simpler! Also, we might want to do this more explicitly with some UX improvements

[Glandos]

This would be "solved" by fixing #471. However, for things like this, I would much prefer having options in the project settings to do that: Splitting a project according to some criteria, etc. Having a subproject feature seems overkill in this situation.