Custom Balances Extension: Questions and Answers
Stuart Beesley has developed some amazing extensions (Toolbox!) for Moneydance, but I feel one needs a bit more attention and usage - Custom Balances.
It's on my top right on my summary page. To put it simply, it allows you to create balances to view, on your summary page.
But it's much more powerful than that.
It's basically a custom report generator. You can create your own reports to view, and flip through them with the group id filter (i.e. a group id identifies a specific report you made)
It's basically a custom view into multiple reports. You just add another group id (i.e. "CustomView") and you can see important lines from multiple reports you created.
It's basically a warning window - you can place in hidden rows that trigger if a problem value is found (i.e. too low, too high, etc) and it will suddenly show up, and even blink if necessary.
You can change colors, show title bars, separation lines, etc.
You can do ratios, percentages, and so on. You can show categories by timeline - i.e. how much did I spend on gas THIS MONTH, or THIS YEAR?
It's uber powerful.
That said, anything uber powerful might elicit "how do I do this or that" questions. So far, these questions have shown up in "strange places" or in threads with a totally different title. As Stuart's main tester for Custom Balances, I can certainly answer such questions, and Stuart will probably check in as well. We would also entertain suggestions for improvement, but we both think CB is fairly mature at this point.
So, feel free to ask about Custom Balances here. It's a FANTASTIC extension (IMNSHO - in my not so humble opinion)
Showing page 7 out of 11. View the first page
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
181 Posted by Stuart Beesley ... on 01 Jan, 2024 11:00 PM
So can the extn do what you want another way?
182 Posted by robert.l.spauld... on 01 Jan, 2024 11:34 PM
@ Stuart I'm not a math wiz, but feel as though I've gone at it from multiple directions. I don't think I can get the final numbers needed. I was excited to finally get an accurate estimate of my taxes with already collected data. Everything I can calculate with your extension matches perfectly with last year's numbers. (proofed). It still requires me to get the calculator out for the last leg.
The last touch, icing on the cake was gonna be calculating refund/taxes due. Which required that final sum:(calculated due, estimated paid). That is an easy one since all income and CG are taxed at a known fixed rate.
The more complicated calculations with variable rates can almost be done as well, but the final result cannot be produced for the same problem.
I've used your junk category idea to enhance reporting by adding Categories for Standard Deductions and Capital Gains all summing to 0. Now available in your extension and MD reporting, without having to do any additional math.
I'm going to play around and see if I can do the same for tax rates. Allowing a one stop shop to update annual rates and withholdings without having to touch the row calculations after they are proven to work.
I"ve been in this hot and heavy for the last couple of weeks (Tax Season), but don't want to become a CPA.
I do run Quicken as well and most of these things are already available there, but would love to ditch them entirely because of the SaaS issues. I hate paying them for their continued inability to fix anything.
Thanks again for all of your time and patience dealing with my silly questions. You and @dtd are doing good things.
183 Posted by dtd on 02 Jan, 2024 12:06 AM
As you might assume, Stuart and I are talking/debating, but we've both spent the second half of December (including Christmas and up to 2024) making these changes, so are quite tired of CB at the moment....
That said, the whole concept of improvement is to reveal other ways to improve (your two concepts about rounding and uor issues (summing rows is just one part of this) have been on my mind for some time, just wanted to hear it from someone else).
But not yet. We both said "maybe later" to more changes, because every concept has a "how do you do this" involved (rounding vs hiding toward x) is much simpler than most. The uor bit is much more complex.
So, it does all work (no bugs found yet, right?), but as to further enhancements.... maybe later.
184 Posted by robert.l.spauld... on 02 Jan, 2024 12:26 AM
Excellent, I look forward to future enhancements. You two are on the ball and have a good system of back and forth.
Been using MD for ~15 years and have always felt it to be 95% solution (Reporting, CG, Return of Capital, Planning,...). With the addition of extensions that gap is closing, and with dedicated developers that actually care it will get there.
I'm twice retired and now have time to fiddle, with my hobbies. Computers and software user. My coding abilities are limited to google some VBA and paste it into Excel to build something that kinda works. I"m used to being able to tweak a set of data to get the desired results. You guys are the men behind the curtain, and most of us are not aware of all the gory details.
I'll keep an eye on the forum and new releases, and I'm always happy to try and break things, it's my specialty.
Thanks
185 Posted by dtd on 02 Jan, 2024 12:27 AM
I do think you know that "Maybe Later" for Stuart is shorter than for most other folks, but he usually recruits me as well for testing/ideas - and I just moved to a new house in December...
As for making things work - I had to change my entire IRA category structure to make things work in CB - because if you simply do an account to account transfer, there is no real way (ever, at all) to keep track of it - so I did something similar to CG calcs, my IRA movement goes to a "IRA withdraw" category, and the movement to a regular account has an "IRA deposit" category (similar to what you and Stuart do for CG) as a way to grab that information for a CB result.
186 Posted by robert.l.spauld... on 02 Jan, 2024 12:43 AM
5% Bubble gum and baling wire, is what it takes to get MD to 100%, it's good to have a purpose. Here is to a New year of keeping up with all the work arounds.
And no bugs that I have found.
187 Posted by dtd on 02 Jan, 2024 01:12 AM
Ok, if you can break things, that almost always means you have an opinion.
Right now, there is one uor/operator field per row. And Stuart instituted uor chaining between different rows for more flexibility.
With this new version, and instituting constants (and thus more uor usage) one uor in a row was fine, but now it seems limiting.
MY potential solution is to allow more than one uor WITHIN a row. Stuart is properly discussing complexity if we do that (circular uor's, infinite loops, uor conflicts)
So two questions, (that anyone can answer),
1. If we institute multiple uors/operators within a row - HOW MANY? As Stuart posted, where do you stop? Current answer is one, obvious first answer is two (i.e. add a second, for example: constant row calc)... but how many till that moves from direct and understandable to ponderous and much more complex.
2. If we institute multiple uors within a row - but can't handle the complexity of both this new feature AND uor multirow chaining (having both creates an entire new dimension in the calcs and conflict) - which of the two is more meaningful? Doing both would take a bit of work to make always correct, or at least throw warnings.
188 Posted by robert.l.spauld... on 02 Jan, 2024 12:50 PM
Seems use display value vs calc value might be an option.
In other words treat other rows as values vs calculations for multi uor calcs.
(value + value -value) * (value)
189 Posted by Stuart Beesley ... on 02 Jan, 2024 11:58 PM
It’s taken me quite a bit of time to (re)understand how CB rounds when hide decimals is selected and also when hide row when x is selected. When both are selected, then it rounds towards x. This is effectively a clever round down, towards x as the target. Otherwise it just truncates. @robert suggested we round up/down when truncating. On reflection this would then mean just hide decimals does round up/down, but when also hide when x, then it’s rounding down. This seems inconsistent to me. So, thoughts all? Thanks.
190 Posted by dtd on 03 Jan, 2024 12:10 AM
@robert - not sure I understand what you propose.
Could you define "display value" versus "calculation value" in your mind?
191 Posted by robert.l.spauld... on 03 Jan, 2024 01:38 AM
@Staurt I have a % calc that comes to 11.51% if I hide the decimals, not the row it displays as 11%. I would expect that to display as 12%. IMHO, of course if the row was used in another calc, I would assume the 11.51% was used for the math.
@dtd Back to the idea of an expression builder that would allow for user created oder of operations on multiple rows (results) (<row1> + <row2> - <row3>) * <row4>. This concept would just use the displayed results from the extension on the summary page and not force the recalculation of those rows. I assume that if a rows result is displayed on the summary page, that it has already been calculated and it's result is stored in memory or a variable of some sort and should not need to recalculated. In my simple mind most rows are calculated on program launch and really don't change again during a typical session.
I don't think I have my head around the actual issue with combining the displayed results from multiple rows to get the desired outcome. In my mind the issue with this is that the combined rows are all trying to recalculate at the same time. I'm probably way out in left field and over simplifying, but thanks for asking.
192 Posted by dtd on 03 Jan, 2024 02:22 AM
@robert - Thanks for the explanation. As you say, you are close, but don't have your head totally around the details. No problem - it's good to see how you interpret the situation, and it does make me pause for thought in how we should best put in a potential second (or third) uor/operator field into the mix for each row.
Still, how many of these fields (currently 1 per row) do you think you would need? Obviously 2, given the constant bit, but you might point out use cases where you'd need more.... (I need one extra uor field to do the summation bit you've mentioned, i.e. basically (a+b)/c [using letters since row numbers would be confusing]) --- you pointed out a/c and b/c and that you couldn't sum them, but that's the same thing as (a+b)/c or (a/c + b/c)
193 Posted by dtd on 03 Jan, 2024 02:46 AM
Stuart - expressed well, but one add: the hide decimals isn't always round down, it's round toward x - so if x is larger than the value, it's a round up - i.e. .44 would round up, not down.
194 Posted by dtd on 03 Jan, 2024 02:47 AM
I think this is my last "conversation" message - I'll be moving further comments to Stuart/myself - but very willing to hear thoughts from others on this "public" conversation bit.
195 Posted by robert.l.spauld... on 03 Jan, 2024 02:50 AM
@dtd theroretically you would not need uor operators, if you could just take base calculations results and combine them using your own order of precedence.
math in cell kind of thing using other rows results as the pieces, maybe even assign your own result names.
row 1 = TaxRate
row 2 = CGRate
row 3 = Income
row 4 = CG
(TaxRate*Income) + (CGRate*CG)
This could be a totally unique kind of row, built to taste.
196 Posted by dtd on 03 Jan, 2024 04:34 AM
Without operators, how do you know you are trying to multiply TaxRate and Income, as well as CGRate and CG, and then adding the two together?
You show the operators in the last line, but not how/why/where/when they come from...
i.e. you've left out some of the "how to get from here to there"...
Are you saying CB should emulate(write and program) formula creation as exists in Excel? (i.e. =(row1*row3)+(row2*row4)?) That would still be a "uor(s)" calculation, just with a different entry methodology. And you definitely would still need the operators.
That would also probably involve abandoning the entire calculation process beyond the picklist, or changing it drastically. Basically a rewrite of the entire program. (i.e. do you start with =<rowcalcresult><average date range +MONTH>+<rmccalc> etc?)
Yes, I can do a rebuttal as well, I'm just trying to show that it isn't as simple as might be thought. (i.e. easy rebuttal ) do <rowcalcresult> as is done now, then replace uor(s) with rewritten excel formulas.
Even with a uor rewrite in the Excel mode, we still have to handle circular references as well.
197 Posted by dtd on 03 Jan, 2024 04:48 AM
You just got to see my side of the type of conversations that Stuart and I have when we debate modifying/improving/changing CB.
198 Posted by Stuart Beesley ... on 03 Jan, 2024 07:40 AM
@Robert. To clarify. All rows recalculate every time you click away from the Home Screen and back, or whenever a transaction is created/modified/deleted in some way. There are potentially more sophisticated methods, but not going there. The recalcs happen in the background on separate threads. If you enable debug mode. Click away from Home Screen and back, you will see the update pause and how long it takes.
199 Posted by Stuart Beesley ... on 03 Jan, 2024 07:59 AM
… PS… a row using another row, ie consuming a uor, does not trigger that other row to recalculate. As you would expect, each row”s result is in memory until the next recalc. So when you use UOR you simple consume the in memory value (which would have always been calculated milliseconds earlier).
On the (a+b)/c proposal, I do like it. It solves all the ‘issues’. UOR chains would have to go away, and I see no way to migrate / upgrade settings from UOR chains to UOR formula (big problem for some). However:
- this feels a little like reinventing Excel - parsing the formula could be problematic - determining the resolution order(s) of the actual rows referred to (eg abc) would be very tricky; double-tricky if the formula rows can be referred to in other row formulas. Unless of course formula rows are special and can never be consumed in other rows….
200 Posted by dtd on 03 Jan, 2024 08:41 AM
"Formula rows" not being available to uor rows would solve a lot of issues.
Just having a flag is pretty easy.
201 Posted by robert.l.spauld... on 03 Jan, 2024 12:42 PM
Thanks all, very helpful to my understanding of the mechanics (recalculation). Again love the extension and use it daily. Another tool in my financial life.
I understand manipulating data is a very user specific thing, and everyone has several opinions on the approach. None better than the other, just different. MD is often maddening with the lack of formatting reports to taste. (columns, calculations, alignment, grouping,...)
Excel is possibly one of the best programs ever written, too bad more financial apps don't provide an add-in that would allow endless manipulation of the underlying data.
I always do all of my calculations manually, then attempt to automate and check against actual data. So much of what I attempt is forward looking and relies on estimates based on historical data. Your tool greatly helps.
202 Posted by Stuart Beesley ... on 03 Jan, 2024 01:08 PM
I'm thinking of dumping round-towards-x target when 'hide when x' is set and simply switch to round(x,0) (using Python) whenever hide decimals is ticked... I don't know why I even did round-towards in the first place rather than round(x,0) - other than in java you get the wrong result with round, but with Python you almost get the right result (refer: problems with floating point numbers)...... This does mean that with x target of 2, 2-2.4999 would yield 2, and 2.5-2.999 would yield 3 (rather that 2 to 2.999 yielding 2). I'm also going to move the rounding to the calculation engine (very last step) rather than display only (but maintain internal precision)... 🤞
Thoughts?
203 Posted by he on 03 Jan, 2024 01:22 PM
@Stuart
As they say in the southern US, I don't have a dog in this fight, meaning I'm not directly impacted by your actions but... this is, in my humble opinion, exactly how rounding should work.
204 Posted by Stuart Beesley ... on 03 Jan, 2024 02:41 PM
The original concept of the extension was to net credit cards and bank accounts to zero. Hence with -0.9999 through +0.999999 with hide decimals and hide when x=0 I think I wanted that range to become zero and hide. But I agree that half round up is probably ‘better’.
205 Posted by Stuart Beesley ... on 07 Jan, 2024 07:36 AM
OK, I've just uploaded PREVIEW 1045. Included:
Hide decimals now ALWAYS rounds the result (0.5 becomes 1.0). Auto hide round-towards x has now gone and it's just rounding.
New row formatting code popup viewer/selector button
New (extra) row selector popup, this one shows the resolved row name, next to the original row selector popup.
New 'tag' field. FOR FUTURE USE. You can name/tag a row. This is like naming a variable. In the future, if and when formula are allowed, then this will be used.. It has no real purpose now, but you can name/set up rows for the future. NOTE: Do not use tags such as 'row1' for row1 - this is unnecessary.
ENHANCED. FMC (Final Row Maths) has a new option.. 'Absorb FMC upwards into other UORs'. This allows the the FMC calc to roll up into other / consuming UORs.. Currently it just works on that row only.. This is optional. Existing rows/maths should be unchanged...
Latest on my site:
https://yogi1967.github.io/MoneydancePythonScripts/
The basic test is whether your existing rows are identical / unchanged.. Before you install any new version I always recommend backing up settings using CMD-SHIFT-B on the current version...
Let me know how this works for you? Thanks
206 Posted by dtd on 07 Jan, 2024 08:32 AM
Look for < to the right of row name for one, and look for another arrow(s) to the left of select row.
207 Posted by he on 07 Jan, 2024 10:30 AM
Can confirm that after downloading latest version, all row amounts are identical to version previous. I've not yet tested the improvements/enhancements in the latest version.
208 Posted by Stuart Beesley ... on 07 Jan, 2024 10:54 AM
👍
209 Posted by robert.l.spauld... on 07 Jan, 2024 02:06 PM
Very slick, all very nice improvements. Still working out the absorb FMC upwards. Thanks
210 Posted by Stuart Beesley ... on 07 Jan, 2024 02:10 PM
Not surprised. It took me a loooong time to think that one through.