Bug causing number of shares to change when entering investment transactions
This annoying problem has been around for some time (over a year). I hoped that updates would fix the problem but it hasn't.
Background
For my brokerage accounts, I download and import transactions as CVS files. The Description, Memo and Amount fields are populated, but the Action and Security fields are not since I know no way of doing this. This means that I need to hand edit each one to enter the correct security. The sequence that I go through for each transaction is as follows:
Select the Action from the drop down. (Let's assume that it's a Buy or Sell.)
Select the Security from the drop down. [ This sets some default Price which causes the imported Amount to be overwritten.]
Set the number of Shares and enter the correct Amount.
Hit <Enter> to save.
The Problem
Sometimes when I save the transaction, the number of shares changes! [Example: I've bought 12 shares for $240. After I hit <Enter> the number of shares changes to 120 and the price per share decreases from $20 to $2 but the Amount remains $200]. What makes matters worse, is that the Price History for the security now reflects a price that's off by a factor 10. That bogus price must now be hand-edited to remove. Simply correcting the transaction afterward does not change the price in the Price History. Moreover, when this occurs, it propagates to subsequent transaction edits, I'll call this the Event Trigger (explained later).
Investigation
Here's what I've discovered.
1. The problem occurs when selecting a security that previously existed in another account and has been added to this account [Actions -> Add Security-> select from list]. The problem does NOT occur with securities that are newly created.
2. The problem does not occur with every preexisting security, but does occur with most (90%).
2. When the problem occurs, it sets the Event Trigger.
3. When I update the next transaction after the event trigger is set and the Security selected is not one of these problem securities, the behavior occurs in reverse. [Example: Buy 12 shares at $240. After saving the transaction, the number shares changes to 1.2 and price to $200.
4. Because the event trigger has now been set, this problem behavior will continue through edits of subsequent transactions. The event trigger will re-set when a transaction is re-edited and corrected.
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
1 Posted by Stuart Beesley ... on 15 Mar, 2025 01:43 PM
Hmm. Odd. As far as I know, MD does not recalculate the qty. can you capture a video of the screen showing this happening?
2 Posted by C M Grau on 15 Mar, 2025 09:40 PM
Hello Mr Toolbox,
Attached is a video that I created on my MacMini that demonstrates the
problem.
I am reluctant to send the .moneydance file for both privacy reasons and
its size (604 MB) but I will cooperate in any way to resolve this problem.
Of note: I tried to duplicate this problem by simply creating entries that
mimicked what the imported transactions. I then went through the steps in
the video. The share number errors did NOT occur. This means that there is
something different about the csv imported entries
I've been a user of your product since 2010 and have been a fan. Here are
the things that I value which product reviewers never consider:
- its core design is clearly well thought out as evidenced by its ability
to scale nicely, and the relatively few 'core' bugs reported
- written in Java (at least used to be)
- it handles multiple currencies well - a feature that was critical for me
and drove me away from Quicken
- it doesn't crash! The only time this happened was when I was using a
machine that was running out of memory and swapping constantly.
Features I wish Moneydance had,
- the ability for users to design their own reports and set all kinds of
report criteria (e.g. row sorting criteria) A particular problem for me is
that I may have 100+ trades in a day, it's difficult for me to find an
error if I can't create a report that orders things exactly as the
brokerage report does. (I know, I know, the software wasn't designed for
this and I'm not a typical customer. )
Anyways, Thanks for the help.
-Christian
IMG_0110.MOV
<https://drive.google.com/file/d/1-_oux13-zEo6zWLMYyQJzWgrQeCXRuXN/view?usp=drive_web>
3 Posted by dtd on 15 Mar, 2025 09:55 PM
Not addressing your issue, but if you have a 604Mb file, you either have a ton of attachments, or you need to use the Toolbox extension to shrink your dataset.
Toolbox, update mode, advanced options, shrink dataset size.
Always do a backup first if you pursue this.
4 Posted by C M Grau on 15 Mar, 2025 10:12 PM
Hello dtd,
I only mentioned the file size because I never had any perspective on
whether it was atypically large or not but did suspect that it was on the
large side.
I am rather anal about recordkeeping. I have transactions going back to
1980 which I backfilled from my Quicken vers. 3.0 on Windows 3.1 bought in
the early 90s.
I finally ended up splitting all transactions that were pre-2000 out into
another Moneydance file in 2012.
Just so you know, I have no attachments in my data file. I will do as you
suggest and see how the dataset cleans up.
-christian
On Sat, Mar 15, 2025 at 5:56 PM dtd <[email blocked]> wrote:
5 Posted by dtd on 15 Mar, 2025 10:27 PM
I have 35+ years of data (every item I've purchased and stock owned since 1988), have never split out transactions from the database, have no attachments, and a shrink took my database below 100mb...
It slowly grows with the unnecessary items. so I shrink it about 3-4 times a year... takes about 5-10 minutes.
Just presenting what shrink has done for me on 1988-2025 data.
You of course, decide what is appropriate with your data/datafile.
6 Posted by dtd on 15 Mar, 2025 10:30 PM
Oh, when it asks for "days to keep 1-30", just say 1.... (i.e. throw away all unnecessary items through yesterday...)
7 Posted by dtd on 15 Mar, 2025 10:35 PM
As with everything in Toolbox, Stuart has done an amazing job providing tools for users.
When you get his attention (and you have), he figures out the issue (doesn't mean he can solve it, that's up to IK/MD changing things if anything is wrong)
8 Posted by Stuart Beesley ... on 15 Mar, 2025 10:44 PM
I clicked the video link and have requested access. Please grant it?
Use toolbox. Shrink dataset to reduce file size.
Use extension extract data, there is an option to extract investment transactions to Csv for loading into excel. Then you can build your own filters/sorting/reports.
I’ll await access to your video.
9 Posted by dtd on 16 Mar, 2025 01:42 AM
Ok, I've seen this before, quite often. The generation of the trigger (for me, as I haven't created/grabbed a new security) is changing the security of the transaction.
For me, this is usually on a download (not CSV import) that has everything mostly right, but doesn't quite have the action step correct (i.e. it doesn't even have the security, but instead usually has a transfer account (which for me is Cash-D). So I change the action step, enter a security, change either shares or price (depending what needs adjusting) [edit: you don't need to change anything else, at times], and the shares/cost change by a factor of 10 (occasionally 100)
However, in testing just now, it is fairly easy to duplicate versus your scenario of do this do that, or my scenario of do this do that.
Simply go to a buy or a sell, which is perfectly correct, and change the security, and hit enter. You will likely get this event. As you say there does seem to be a "trigger" in that sometimes you try to reproduce the action, but the factor of 10 does not jump into the picture.
Hmm, continuing to play with my scenario, if I change the security to a lot based security, I get a divide by 10, if I change the security from a lot based security to a non-lot based security, I get a multiply by 10. [this isn't the only way to get divide/multiply by 10, but it seems to be more consistent than changing security from A to B, that sometimes makes the change and sometimes does not]
So I haven't totally sussed out what actually does cause a trigger, and there might be more than one situation that causes the change.
10 Posted by Stuart Beesley ... on 16 Mar, 2025 07:41 AM
When you change securities, are they different between 4 and 5 decimals?
11 Posted by Stuart Beesley ... on 16 Mar, 2025 10:48 AM
Confirmed. It's a bug.. Simply edit a txn and change the security to another with a different number of decimal places - e.g. from 4 to 5 which I am guessing is your scenario, and then an extra zero or decimal place will get stored.... Not sure of the fix yet. A temporary workaround is to make all your securities have the same decimal places.
12 Posted by C M Grau on 16 Mar, 2025 12:54 PM
Hello dtd,
The idea that lot-based vs. non-lot-based securities is an element of the
problem is intriguing, however a lot object must be tied to an account and
a security - perhaps through a separate security/account instance.
Now in my case, none of the securities involved - Monster Beverage, Verisk
or Elastic has lots enabled, nor are lots enabled in any other accounts
that contain these securities.
Conceptually, it would seem to me that Shares is the one immutable entry in
an investment transaction unless that field is changed by the user. I can't
think of a reason why the software would change the number of shares in
response to a price or amount change. Even a stock split shouldn't change
the share amount. I'd be taking a hard look at any code that sets the share
number.
On Sat, Mar 15, 2025 at 9:42 PM dtd <[email blocked]> wrote:
13 Posted by C M Grau on 16 Mar, 2025 01:04 PM
Sorry, I may be confusing the issue. My thought was that the video showed
exactly that with the share number changing up and down by a factor of 10.
14 Posted by C M Grau on 16 Mar, 2025 01:19 PM
I can confirm that you're on the right track. In my instance the "old"
securities (Monster Beverage, Verisk) do indeed have 4 decimal places in
price, while the new security (Elastic) has 5. At some point the default
number of decimal places increased from 4 to 5. Imagine if I'd set all of
my US stocks to 0 decimals while my US mutual funds had 4 and UK securities
had 5. This problem would have been worse.
My problem is that I have about 1000 securities to edit. I can do if I must.
I don't see a configuration setting for default decimal places, is there or
should there be one?
15 Posted by Stuart Beesley ... on 16 Mar, 2025 02:36 PM
There is no default. I agree it’s a pain. Let’s see if we can fix the issue.
16 Posted by dtd on 16 Mar, 2025 04:06 PM
My comment on lot based securities was simply an observation. This was experimental searching, so was commenting on what I saw. Most of it was to give Stuart some information to investigate. Apparently it is decimal places, not lots or other things. The lot-based security I picked that was consistent in displaying the issue did have different decimal places versus most of my other securities.
Given your comments, would you have preferred that I waited to respond that I saw the bug/issue until after I had reached conclusions versus observations?
17 Posted by Stuart Beesley ... on 17 Mar, 2025 03:08 PM
I've been working with the IK developer on this bug, and I'm informed that there now is a bug fix in place that will appear whenever the (first) 2025 alpha appears..