Possible use case - comparing projections by sets of item adjustments

[UNLV-ShaneD]

In retrospect, filtering items may not be helpful in decision making. It may be more useful to compare two or more options (which would create two or more different plots).

One way of achieving this is to have different sets of item adjustments. You can have a set of item adjustments for the status quo. Then, you can have a set of adjustments that includes, for example, eliminating all income and fuel items. Then, a set of adjustments that simply cuts income items by half. The three sets of adjustments would then be projected and plotted on the same chart.

This use case has most impact on tagging, item managing, and charting. It makes managing item adjustments a bit more complex - but the added functionality may be well worth it. To reduce scope, we can take away filtering from the charting and projecting jobs as they do not seem all that useful. As the system is now, if they wanted to compare two sets of adjustments, they would have to redefine all of the affected adjustments for each scenario (not fun).

[strongd]

As the system is now, if they wanted to compare two sets of adjustments, they would have to redefine all of the affected adjustments for each scenario (not fun).

I agree, that would not be very good for the user.

So, if I'm getting this right, these sets of adjustments would be predefined for the user to select from like a menu or whatnot?

[UNLV-ShaneD]

The glossary entry for "seasonal" helps make some sense of this:

seasonal Some recurring transactions occur at different rates depending on the time of year (e.g. fuel expenditures may increase during school sessions) and thus require a frequency adjustment Some recurring transactions may decrease in value for small periods of time (e.g. vacation may decrease electricity bill) and thus require a value adjustment

   Note that seasonal adjustments may be recurring or non-recurring
   Adjustments may stack
   Adjustments may persist indefinitely

So, we'll have a base adjustment class and have a few different types of adjustment classes extending that. There will be predefined adjustment types, but the user can put multiple adjustments on an item.

Now, when we want to compare a few different budget scenarios, there are a few things we will need to account for: -Ability to change expected item values between scenarios -Ability to change expected item dates between scenarios -Additional items

The first two can be addressed by playing with item adjustments. Let's have a user story: Bob has a budget. He thinks he may be getting a pay raise, and if so, he wants to know if he can pay off his car a year earlier. So, he uses our software to create a branch off the budget. On this new branch, he puts an item adjustment on his income item - increasing its value indefinitely, starting on the date of the possible pay raise. He places a second item adjustment on his car loan item - increasing its value to its maximum. Then, he goes to the charting page to plot the two budgets on a single chart.

Note a few subtleties: -Bob made a branch off the master budget. This branch consists of only additional item adjustments. Since the branch doesn't keep track of actual transactions, the branch will be updated as more data is scraped and Bob gets closer to the pay raise - so he can chart the budget and its branch later on without mucking about. -Recurring items will need to have an associated maximum value (and possibly APR for a simple interest calculation) -Creating additional items under a branch is not possible under this system. As a work-around, the user would have to add a zero-value item to the main budget and do a value adjustment to it under the branch. Perhaps this can be automated a bit to make it more user friendly.

[UNLV-ShaneD]

New glossary term identified: budget branch

I'm adding this to the project scope. Filtering is no longer necessary in the charting and projecting aspects of the project.

budget branch a variation off of a budget (or another budget branch), consisting of a set of item adjustments note that a budget branch does not consist of actual transactions. it can create additional projected transactions (as that is one possible side-effect of an item adjustment)