+50 -50 doesn't change want

[iffy]

I have a bucket that wants $100, and I put $50 in, but then I realized I didn't want it in that bucket, so I did -$50 but the want column stayed at $50

[iffy]

I'm not exactly sure how to fix this because it can get tricky trying to determine if the in/out of a transaction is meant to affect Want. For instance, we recently had a surplus in our babysitting bucket, so we moved a bunch out toward other buckets. The bucket still got its rain that month (we didn't want the Want to go down); we were just using it for stuff.

[Limezy]

I'm not sure to understand this issue ? If I have a bucket that wants 100. I put 50 in, then 50 out, the want stays at 100 ! [EDIT] OK understood, you mean the first value on the small frame.

[Limezy]

Why these issues ?

To solve this issue, I believe you need to have an exact philosophy about what what are « Want » , « Activity », "In"... Problem is, as you say it, the philosophy of those depend on the way you use a bucket ! And as you point it out on this thread https://github.com/buckets/application/issues/86, we have the same bucket for different usages !

This is why I believe the problem can be easily solved by introducing new types of buckets, each of which will have different ways of dealing with new rain, want...

Allow me introduce you those buckets

The "measuring glass" bucket

I believe this should be the standard bucket (apart from plain old bucket).

The Want behaviour

• This guy always wants its balance to be 100 or more at beginning of each month
• The first month, it will "want" 100 because its balance is 0
• The next month, if 20 are left, it will "want" only 80
• The "want" will always be refering to last month's last day's balance (e.g. 20)
• If you put in more, or if at the end of the month it has more than 100, then it will "want" 0

The Transfers and transactions behaviour

• Positive transfers will not be shown in activity
• Positive transfers will fill the want and be shown in the "In" (as it is currently)
• Négative transfers will not be shown in activity
• Negative transfers will increase the want (compared to last month's last day's balance) and be substracted from the "In" I cannot understand why it is not currently like that! For me, negative transfers should have the exact opposit behaviour than positive transfers!
• Negative transactions will be summed to activity
• Positive transactions will be summed to activity

The "overflow" bucket

The Want behaviour

• This guy always wants its balance to be exactly 100 at beginning of each month
• The first month, it will "want" 100 because its balance is 0
• The next month, if 20 are left, it will "want" only 80
• The "want" will always be refering to last month's last day's balance (e.g. 20)
• If its balance is more than 100 at the end of month, then at begining of next month it will "give" all remaining rain (kind of negative want currently)
• So maybe the "Want" column should be renamed "Want / Gives"

The Transfers and transactions behaviour

• Positive transfers will not be shown in activity
• Positive transfers will fill the want and be shown in the "In" (as it is currently)
• Négative transfers will not be shown in activity
• Negative transfers will increase the want (compared to last month's last day's balance) and be substracted from the "In" I cannot understand why it is not currently like that! For me, negative transfers should have the exact opposit behaviour than positive transfers!
• Negative transactions will be summed to activity
• Positive transactions will be summed to activity

The piggybank bucket

The Want behaviour

• This is the recurring expenses bucket as it works currently
• This guy wants to receive 100 rain each month, no matter what's its balance
• It's kind of the less I buy on it, the fatter it becomes and one day I will break it for savings or transfer all rain to the "new camera" bucket.
• If the "In" is 100 or more, the want will be 0

The Transfers and transactions behaviour

• Positive transfers will not be shown in activity
• Positive transfers will fill the want and be shown in the "In" (as it is currently)
• Négative transfers will not be shown in activity
• Negative transfers will increase the want (so that the In becomes at least 100 if we give the want) and be substracted from the "In" I cannot understand why it is not currently like that! For me, negative transfers should have the exact opposit behaviour than positive transfers!
• Negative transactions will be summed to activity
• Positive transactions will be summed to activity

The Save Z/mo until infinity bucket

Sorry, just figured out this one is exactly the same as piggybank !

Do these new buckets solve your problems ?

Yes, I believe so !

• Cykedev from Issue #86 will use the "Save Z/mo until infinity" bucket and this bucket will have a consistent behaviour to what he is expecting
• If you use a "overflow" bucket for your babysitting, and if one month you used only 50 instead of the budgeted 100. Then, the next month, this bucket will only want 50 which will virtually give more rain for other stuff !

[Limezy]

Sorry did some edits to make things more clear.

[Limezy]

Regarding "In" and "Activity" behaviours, In a nutshell, for me the "In" should reflect the sum of transfers made to the bucket (including rain) The "Activity" sould reflect the sum of transactions corresponding to the bucket

Therefore we always have this equation true no matter which bucket we are in

Last month's last day's balance+In+Activity=Current balance

Which IMHO really makes more sense and has a mathematic consistency

[Limezy]

Therefore, when set to B (e.g. B=100),

• The Piggybank and Save Z until infinity buckets always adjust their want so that the following equation is true

Want : In>=B

• The Overflow bucket will always adjust their want so that the equation In = B-Last mont's last day's balance becomes true, which can be reduced to

Want : Current balance - Activity = B

• The measuring glass bucket will always adjust their want so that the equation In >= B-Last mont's last day's balance becomes true, which can be reduced to

Want : Current balance - Activity >= B

[cykedev]

Wow, great thread so far! Really nice ideas, but if you should make it work like explained, make sure the user understands this!

My suggestion is easier:

As I come from YNAB, the behavior I know is, that there is no activity! The only thing there is a goal, similar to a want. And I can assign money to a bucket. Nothing in and out, so no math problems. Ether I hit my goal or not. Transactions only apply to the buckets balance, not the goal.

[iffy]

Thank you for this great and thorough feedback. I will work through it when I have more time and see about adding more bucket types/altering the math. (I love the name "piggybank", btw)

[Limezy]

Hi @cykedev,

I never used nor try YNAB4/YNAB, but I've read a lot on how it works (and this is how I discovered Buckets from the reddit dedicated channel). The most interesting review of it I could find is here : https://mappedoutmoney.com/ynab-review/

However, here is my understanding of it :

• YNAB budgets are similar to "plain old" buckets.
• When you set up a goal, it's like putting money in a bucket for the month. So it's not the Want, it's the In. Each month you'll have to put a goal (put some money In) manually on the budgets. They will not tell you what they "need" = want.
• There is indeed "activity" because they will tell you how much has been spent / reimbursed on each budget.
• When you overspent, it will ask you if you want to cover those expenses with another budget. This is exactly like a transfer between two buckets, which will increase one In and decrease another In accordingly (well, currently it will not decrease the other In yet I hope Matt will solve that !)
• So if you want to recover your YNAB habits, I would advise to use only plain old buckets. You will have no Want, and you can just act like if your goals are your In. You will track your expenses so that your balance never reaches 0. At the end of each month, you will set each bucket balances to 0.

Buckets mechanics are a bit tougher to understand yet are way more powerful IMO, for two main reasons :

1. The first is that Buckets's buckets can carry on positive and negative balance. YNAB budgets can only carry on positive balances. This makes possible solving some of the "cons" in the review I linked (see up). For example, I have some buckets to track my reimbursments. If my employer reiburses me one month later, I will still be able to carry a negative balance (knowing it should come up to 0 some day) and check everything is OK the next month.
2. Matt added this Want feature which I find both extremely difficult to understand perfectly (took me several days to be sure) and extremely powerful. This is a great help to go faster when budgeting your month. It's also a great help to "pre-budget" several months on the future, to have an idea of what will be your expenses / cash flows etc...

[cykedev]

I’m indeed very exited about what will happen with this feature. The only thing I wanted to say is, that it does not have to be to complicated to be a useful tool, and that the meaning of the solution has to be understood by the users. Otherwise it’s a wast of effort it takes to implement.

But I also like the ideas behind the want.

[Limezy]

@cykedev I strongly agree with you that unless those buckets are explained in a very simple way to end users, they will not be used / baddly be used. In my previous comments, I put some math because it's necessary to understand the core mechanics of each bucket type. Nevertheless, it doesn't mean it has to be displayed on the software.

One workaround would be to have some "basic" and some "expert" bucket types. "Expert" bucket types would be disabled by default.

Here are some "end users" explanations I could think of :

The "measuring glass" bucket

This bucket makes sure you have at least B money for your corresponding expenses at the begining of each month.

• If the balance is more than B at the end of previous month, it will want "0" rain for this month.
• If the balance is between 0 and B at the end of previous month, it will want as much rain as needed to set balance back to B for this month.
• If the balance is less than 0 at the end of previous month, you overspent ! It will ask as much rain as needed to set balance back to B for this month.

The "overflow" bucket

This bucket makes sure you have exactly B money for your corresponding expenses at the begining of each month.

• If the balance is more than B at the end of previous month, it will give enough rain to come back to B for this month.
• If the balance is between 0 and B at the end of previous month, it will want as much rain as needed to set balance back to B for this month.
• If the balance is less than 0 at the end of previous month, you overspent ! It will ask as much rain as needed to set balance back to B for this month.

The "piggybank" bucket

At the begining of each month, this bucket will ask you exactly B rain for your corresponding expenses, no matter what's the balance at the end of previous month.

The "Save Z/mo until infinity

Just figured out this bucket type was exactly the same as piggybank bucket ... sorry !

[cykedev]

Well done @Limezy

[Limezy]

Small detail : the piggybank name is not from me. It's from James Cole, author of the awsome self-hosted personal finance management software Firefly-III (https://github.com/firefly-iii/firefly-iii). Great software, although very difficult to install, a bit too much on the report side. The philosophy, not far from YNAB and Buckets, is bit more confusing (budgets / bills / categories...)

[iffy]

@Limezy thank you for this detail; I've filed a new issue (linked above) to track the adding of new buckets (since I expect I'll fix this particular issue before adding the new bucket types and I don't want to lose track of the request to add them).

[Limezy]

Yep you're right, better to have both requests separated.

So as you now know, I believe the best way to solve this issue is to compute the In as the sum of all rain transfers to the bucket, no matter they are positive rain add, negative rain "give", or inter-bucket rain transaction.

In the bucket transactions detailed view, if the transaction is checked as a transfer, it should come to the In. If not, it should go to Activity.

Therefore, when we put rain in a bucket, it should already be checked as a "transfer" in the transaction view. Same when we remove rain from that bucket. (Wich is not the case currently).

Do you agree with this ?

[iffy]

@Limezy I think we are in agreement, though I think I'm actually going to replace the Transfer flag with a flag named either Rain or Activity. A prior version of Buckets used the transfer flag to determine if something was rain or not, but it was too confusing. So here's my current proposed fix:

• The Transfer flag will be removed from bucket transactions.
• Bucket transactions will have a new flag named Activity (or Rain and everything that follows is opposite)
• If a transaction is marked as Activity it will affect the Activity column.
• Otherwise it will affect the In column.

That part is straightforward and should not be surprising. But then the rules that determine whether a bucket transaction is an Activity transaction or not are where the trickiness lies. Tell me if this agrees with what you're thinking:

Action	Current behavior	Proposed behavior
Bucket transaction as result of categorizing account transaction	Activity	Activity
+20 one bucket	In	In
-20 one bucket	Activity	In
+20 one bucket, -20 another bucket, click "Make it so"	+In, -Activity	Both Activity

In addition to this, I'd rather not, but would consider adding an [ ] Activity checkbox next to the "Make it so" button that would determine whether transactions count as Activity or Rain

Thoughts?

[Limezy]

Hi, please find my commentaries below :

Action	Current behavior	Proposed behavior	Commentary
Bucket transaction as result of categorizing account transaction	Activity	Activity	Agreed
+20 one bucket	In	In	Agreed
-20 one bucket	Activity	In	Agreed
+20 one bucket, -20 another bucket, click "Make it so"	+In, -Activity	Both Activity	Both In

For me, to put intra-buckets transfers in "activity" doesn't make sense. Indeed, here is my understanding of Buckets logics (Yes, I know, sometimes we French engineers can be a bit (too much?) picky about logics 🔢 )

Buckets makes a distinction between two different money flows

One is about virtual money moves

• When you put some rain in a bucket, you make a "virtual money" flow
• You move some rain = "money without meaning" to a bucket = "storage of money with a given meaning"
• When you have no rain left, it means all your real money has been virtually given a meaning
• When you remove some money from a bucket, it becomes rain again. This amount of money comes back to a "no meaning given" status.
• The intra-buckets transfers are also virtual money transfers. It's taking an amount of money and change its given meaning (take -20 from "car maintenance" and place them +20 to "phone bill"
• The In sum is here to display the amount of money that was virtually put on a bucket for a given month. This is why I believe the Car Maintenance In from that month sould take into account that you have removed -20, and the Phone Bill In should take into account that you have added +20

Another is about real money moves, from account to account.

• It can be external account to internal account (Bucket describes this as an Income but it could be more detailed, see https://github.com/buckets/application/issues/196).
• It can be internal account to external account (Bucket calls this a Transaction).
• It can be internal account to internal account (Bucket calls this a Transfer between accounts)
• All those correspond to real money moves in the real life
• When there is a real life money move, this has to be input in the virtual money world
• This is the purpose of Activity. It will remove from the bucket as much virtual money as real money has been spent whith this "meaning" in the real life

@iffy does all this make sens for you ? Small summary of Buckets vocabulary :

Item	Virtual world	Real world
Unit	Rain	Money
Storage Name	Bucket	Account
External <> Internal Flow Name	Rain input / output	Income / Transaction
Internal Flow name	Transfer between buckets	Transfer between accounts
Monthly Gauge	In	Activity

[iffy]

@Limezy I like your distinction of Activity being for real life money changes and In/Rain being for the virtual flows. I think it's solid.

My only qualm is this scenario:

• Suppose we put $50/mo in our Babysitting bucket
• After many months, not using it as much as we expected, we have $400 sitting in the bucket
• We take $200 out of it to put into our Vacation bucket

Currently, Buckets would look like this (after doing this with Make it so):

Bucket	Balance	Want % (the blue/green bubble)	In	Activity
Babysitting	200	100%	50	-200
Vacation	200	100%	200	0

The reason I like the Babysitting amount being deducted from Activity is this question:

Did the Babysitting bucket get what it wanted this month? Yes. It wanted $50 and it got it. I just happened to use some of the excess money to bolster the want of another bucket. If I "Make it rain" again, I don't want any more money going into Babysitting.

If, on the other hand, the 200 was deducted from In then, it would look like this:

Bucket	Balance	Want % (the blue/green bubble)	In	Activity
Babysitting	200	-300%	-150	0
Vacation	200	100%	200	0

At a glance it looks like the Babysitting bucket didn't get what it needed this month and making it rain would try to fill it up again.

On the other (other) hand, I could see scenarios where you steal money from one bucket earlier in the month, and later do want "Make it rain" to refill the stolen money.

I think I could be convinced that the last row of the table should be Both In and allow users to manually adjust whether a transaction is In or Activity on a transaction-by-transaction basis. Either would solve the initial problem brought up by this issue :) and I think Both In is probably the least surprising behavior.

Thank you for your thoughtful comments!

[cykedev]

I think that’s the point I tried (little bit bulky and mixing terms used in Buckets) to say earlier:

• moving real money (e.g income, spendings or transfers between accounts) is activity
• putting money in or out of buckets is in

Nothing more special

[Limezy]

@iffy,

At a glance it looks like the Babysitting bucket didn't get what it needed this month and making it rain would try to fill it up again.

Indeed, and this is precisely why I made a proposal to include new types of buckets.

• In this case, if your Babysitting bucket had been a "measuring glass" bucket, because its balance was more than 50$ at the begining of the month, the Want would have been 0 at begining of the month. If you make a bucket transaction from your Babysitting bucket to the Vacation, the want will stay 0 as long as your In stays at more than 50.
• If your Babysitting bucket had been an "overflow bucket", its balance would have never been beyond 50$ at the begining of each month, because all the budgeted money that was not used during the month would have come back to rain at the begining of the month.

Those two bucket types look more adapted for "Babysitting", IMHO, as I don't see why you would want to use for your Vacation some money you have saved from "Babysitting" money. With the current bucket recurring expenses type, you have plenty of savings that are hidden in the individual balances of your different buckets. Better have the buckets auto-regulate themselves by not asking for more when they are full (measuring glass) or never have a balance more than what they are expected to be by "giving" the surplus they have (overflow) !

[Limezy]

@cykedev agreed. I believe that from the begining, the confusing thing was that Buckets tried to cover different usages with the same bucket type, which makes the Want or the In never exactly as you expect it to be !

[iffy]

@Limezy I don't want babysitting to be restricted to only $50; its bucket type isn't the issue to me. I like that it grows and then I manually chop it down to size as needed (and potentially readjust the deposit/mo at the same time).

The column is labeled "In." It seems pretty clear that a column labeled "in" should show the sum of all money into a bucket and not include anything related to money moving out. But all this discussion seems to assume renaming "In" to something like "Rain" (which may be the correct change).

I'll keep thinking about this

[Limezy]

@iffy understood your problem. I have two small proposals :

Fly-over details

• You rename the In column to something like Rain

• The column displays the sum of all virtual money transfers for the month

• In your Babysitting example, "-150"

• When flying over that number, we can see a detailed view just like this one :

  

• This view will split positive and negative amounts

• In your Babysitting example, it will show In : 50 | Out : 200

Optional Out column

• Normal case (99% of the time), we only see a In column with everything that has been put inside the bucket. This In will show the sum of all positive transactions.
• Special case (1% of the time), when we transfer some virtual money out of a bucket (when you chop down one bucket, or when an "overflow" bucket gives money back), a new Out column will apear and show the sum of negative transactions. This Out column is shown only if there was a negative virtual money transaction on the bucket

I like the first one best. What do you think ?

Just to be clear again, my detailed comments in this thread or others are just to propose some improvements for Buckets. The software is really good and already doing great !

[cpo]

Whoa dudes. Great theories sofar! Just letting you know I follow this from the sidelines ;-)

[shanep2300]

Lots of discussion here, but the original 50 in and then 50 out is not a bug. To fix this issue, go the bucket and 'Delete' the mistake amount. If you take out -50 as a transaction, then yes, the want column will stay at wanting 50 because you're budgeting for a total of 100.

If I understood the OP correctly, this is not a bug.

[Limezy]

@shanep2300 I agree it is not a bug. It is more a refinment on how the In, the Activity and the inner-buckets transactions should behave. @iffy what are your thoughts on my fly-over proposal ? Do you think it can solve this issue ?

[iffy]

@Limezy When I get to this issue, I'm going to try various things (including what you propose) and see how it works in practice. Thank you for the ideas!

[tuskpot]

I agree with @Limezy and others that negative numbers should behave the same as positive numbers when entered into the In/Out column of the bucket list. I disagree, though, that new bucket types are appropriate. As @iffy described, it seems like any bucket with recurring deposits could need both kinds of "Out" transactions from time to time.

Instead, I would suggest adding a "balance adjustment" button to the bucket detail page, maybe near the current balance value itself, that would allow a user to unambiguously add or remove money from the bucket's balance without affecting Want progress. Clicking this button could open a small dialog with a brief explanation and a field for entering the adjustment amount. The button could even be hidden if the bucket doesn't have a recurring deposit, since it would have the same effect as the normal In/Out column in that case.

This means that the default behavior when entering a negative number in the In/Out column of the bucket list would always be to "steal money from one bucket to be paid back later that month" as @iffy described, which I think is the safest and most consistent choice. In order to reduce the money in a bucket without affecting Want progress (as in the baby-sitting example), the user would go to the bucket detail page and use the proposed "balance adjustment" button.

There are a few remaining questions that come to my mind:

1. Should these "balance adjustment" amounts be included when calculating the "In" column of the bucket list page?
2. Should there be something in the transactions list on the budget detail that indicates which transactions did or didn't affect Want progress?
3. Should the Want progress pop-up (or fly-over as @Limezy called it) include these adjustments separately? or at all?

(I think the answer is probably "yes" to all of these, but I'm not sure.)

[Hydro8]

@Limezy it's exactly the problem I have :)

How do you handle this problem right now ?

(Ingénieur français ?)