Enable "Register Columns" configuration in settings for Investment registers

The core reason is because the investment registers aren't even close to the same kinds of controls. If you look you will find to this day, they still call them "investment lists", not "registers". They literally started as lists of the transactions, not as a register like the non-investment accounts.

That isn't to say that they can't change some things like add the ability to display the FITID, but the investment and non-investment registers will never have the same functionality.

Here is just some of the differences, there are many more.

• The underline controls are different.
• They display completely different information.
• The non-investment accounts have individual settings for the columns for each account. The investment registers have one setting for all.

One thing you might answer because it would affect the implementation is if you turned on the FITID would it be OK that is gets turned on for all investment registers? Having individual settings for each register and therefore a menu selection like in non-investment accounts would require building out a completely new way of setting/storing/implementing such a system.

@Chris_QPW

Some people may still call it "investment list" but when you click on the gear box in an investment whatever you call it, there are options for "Register row height spacing" and "Register preferences".

Regardless, I see no reason other than a difficult implementation, why users should not be able to control what colums are displayed in the investment thingy like they can with banking transaction registers. I would prefer that choices made would only apply to the account where the action was performed but I could live with it applying to all accounts.

My expertise is not in finance but I do have over 50 years experience in software engineering. There is a process called refactoring which is described by Google's AI as:

Code refactoring is the disciplined process of restructuring existing computer code—changing the internal structure—without altering its external behavior. It improves non-functional attributes like readability, maintainability, and complexity while removing "code smells" (e.g., long methods, duplicate code) to make software easier to understand and cheaper to maintain.

Maintaining code means more than fixing errors, it includes making enhancements. If making enhancements becomes prohitibively expensive because of the code's existing structure, it may be time to refactor the code. In my experience, it saves money in the long run and makes the product more reliable, and probably faster and smaller as well.

Thanks

Jim

Sounds like you and I have about the same amount time in software engineering.

This isn't really about what is "possible", it is about what is the likelihood that they will implement the change based on the existing code and given the resources they have.

I base my statements both on what I have seen using Spy and on what I have seen the Quicken developers do in the past. Spy shows a jumbled mess of controls in the investment accounts, not something that people really want to mess with. This tracks with the history of the code development, and why I mentioned its origins. One might like to ignore the 40+ years of development piled on, but that isn't the way it really works.

And the development in the investment accounts have shown this. For instance, when they finally got around to implementing "edit/move transactions" they didn't do what most people would think and use multiple select in the register. Instead, they popup a completely new window and do the multiple select there. Clearly the developers were avoiding the fact that even though the investment register looks like a nice list, it is far from that.

And then there is the gain vs reward. This idea has a total of 4 votes. For Quicken Windows US they don't even send the request to the developers for ideas with less than 50 votes. And even after that they are going to consider how much work it is. Clearly right now they are only savings the setting for the columns in global settings. Refactoring to have it as individual accounts, is just one more complications that might put it farther down the todo list.

Given that the same development group hasn't gotten around to changing the RMD date for the Lifetime Planner, …

😀One of them is mine. These days I only download one 401K and run it in simple mode, but there have definitely been times in the past where being able to see the FITID would have been helpful.