Per other post topic, creating a stand-alone post for SPLIT issue (Split impacts/ changes Total Cost).

For continuity, here the original scenario:

2 examples -- SAME pre-Split Total Cost, 2 different post-Split Total Cost values, and both have changed from the original, while Total Cost should (I believe) NOT be impacted by Splits, ever:

In case it matters, "Full Precision" selected in both examples:

Scenario A:
a) Buy 275 Shares Stock ABC @ $73.2215 + $0.0166 Commission = $20,135.9291.

b ) 4:1 Stock Split (4 New per 1 Old).

==> With Full Precision, Total Cost post Split on "Current Holdings" tab shows $20,135.9566 ??? On the Transaction Register tab, it still correctly shows the original $20,135.9291. I believe something goes wrong when you calculate the Split -- maybe U use a 4-decimal truncated Total Cost per Share when U "re-assemble" the Total Cost post Split??? Anyways, I am sure you can trace the problem.

BTW: If "Normal Rounding -- 2 Decimals" is selected, pre-Split Total Cost is (correctly) $20,135.93, post-SPLIT Total Cost changes to $20,135.96 (which looks like the rounded equivalent of the incorrect Total Cost per above problem).

Scenario B:
Same “correct” Total Cost value as 2A, just different transactions to get there – interestingly, Total Cost post Split changes again, this time to yet a different (incorrect) value vs. 2A.

a) Buy 50 Shares Stock ABC @ $93.5664 + $25.8509 Commission = $4,704.1709.
b ) Buy 50 Shares Stock ABC @ $87.4053 + $24.8232 Commission = $4,395.0882.
c) Buy 75 Shares Stock ABC @ $74.00 + $28.54 Commission = $5,578.54.
d) Buy 100 Shares Stock ABC @ $54.30 + $28.13 Commission = $5,458.13.
e) 4:1 Stock Split (4 New per 1 Old).

Total Cost pre-split should be (and correctly displays as) $20,135.9291 (same as 2A). However:
==> With Full Precision, Total Cost POST Split on "Current Holdings" tab changes to $20,135.9241 ??? If you sum up all 4 pre-split transactions on the Transaction Register tab, you still get the original “correct” $20,135.9291. Again, it’s the “Split” transaction that caused the Total Cost change.

Again, above just for continuity/ reference, you are aware already. Discussion to continue below now.

Here your reply per your Post#2127:

I think the problem is that if your share price uses all 4 digits, then the share price after the split (original share price / split ratio) really needs more digits. Since our fixed decimal format is limited to 4 digits, there is just not enough accuracy to correctly represent the adjusted share price, and that gets multiplied out into the total. Hmmm... so that's a problem. I will have to look into what can be done about that, because that's an issue with the available accuracy of the number format, not the calculation. This one won't be fixed right away.

And here mine per Post# 2130.

That might well be true. And I wonder if this can even happen if the Book Value per Share is shorter than 4 decimals, but the split ratio causes it to "lengthen"?

For instance, Pre-Split BV per Share is $10.00, Split Ratio is 3:1, I suspect the new BV per Share should be $10.00 / 3 = $3.3333333333 -- would this scenario cause the same problem where as per current methodology, the Total Cost would change due to fact that you store 4 decimals?

BTW -- are you able to replicate how PSM actually calculates the "incorrect" Total Costs of $20,135.9566 in 2A and $20,135.9241 in 2B? Not understanding how Total Cost is calculated (is it adding up all transactions, or is it storing the cumulative 4-decimal BV per share and just multiplying it with # Shares, or something else), I cannot even replicate it in Excel?

OK -- btw, I was wondering whether there is an easier way to "close" a topic, but to "move" select posts from that topic over into a brand-new topic that more specifically deals with a sub-set of the previous topic -- the sub-set that is still "open", so to speak? "Move" a specific Post instead of "copy and paste" the content of a post into a new post within a new topic, which is what I did above.

Anyways, knowing that the Split issue will take a little while longer, I was wondering whether the following could/ should be at the core of a future solution:

When entering a Split transaction, PSM to immediately check -- for each transaction impacted by the Split -- whether the Book Value POST is exactly the same 4-decimal number as BEFORE Split.

To check this, Book Value post Split would be calculated as follows:

# Shares post Split (stored as rounded to 4 decimals)

x

Share Price post Split (stored as rounded to 4 decimals)

+

Commission (post Split -- I don't think this gets split)

+

Fee (post Split -- I don't think this gets split)


IF NOT exactly the same 4-decimal rounded number, PSM to immediately adjust "Fee" for such transaction with a value equal to the difference b/w 4-decimal rounded BV of transaction pre-split and post-split.

You might have to do this for each transaction/ lot that is part of this split.

And we wouldn't just override "Fee" if there was already a value in the "Fee" field pre-split. Instead, add/ subtract from any already pre-existing "Fee" value according the the Delta in 4-decimal BV.

Does that sound like the right "theoretical" solution?

The other variation of this potential solution could be to take the plunge and introduce that previously debated dedicated "adjustment" field in the Transaction register instead of "abusing" the Fee field for something it originally wasn't meant to be. Meaning, keep "Fee" and "Adjustment" separate.

BTW -- I have started to use the "Fee" field manually to bring all my Buy/ Sales transaction values to an exact 2-decimal value. Works so far, however I suspect there might be certain Split scenarios where without the above solution, I might have to manually go in again post future splits and adjust the "Fee Adjustment" amount.

Does the above sound like a possible solutions path to explore for a future release?

I will have to consider what we can do here, but I don't think a complex solution with overriding fields or entering adjustments is the answer. Like I said, this one won't be fixed right away.

Understood it will not be right away.

And here I thought my solution path was simple ;-).

BTW -- can you briefly explain why Split transactions cannot be re-opened once recorded (not even for Viewing)?

I have a few where I added extensive comments in the Notes line, and I cannot read them in the Transaction Register view.

I am sure there is a good reason why they are "locked", can you briefly explain?

And if this cannot be changed, can you offer "Read Only" opening option for Split Transactions ("OK" button greyed out)?

Also, whenever recording a Split, I get a "Adjust historical quotes [Y/N]" dialogue box or something like that -- can you kindly explain what happens if I say Yes or No, and which answer you recommend?

Thx


PS: New features where -- at Full Precision -- it shows up to 4 decimals, but only if required, works great. It makes it so easy to go through entire Transaction history and immediately spot the ones that are impacted by Rounding -- then I can either Round or even adjust the underlying transaction via positive or negative 4-decimal adjustment "Fee", so Rounding is not even required. Just did this through a 12-year transaction history, so easy to now spot the "offenders". Thanks for that!

It can't be edited but it can be deleted and re-entered. This code was written long ago; at some point I'll have to revisit it and figure out if I can't make it editable. The only real issue is reversing the split of the historical data and applying the new split ratio, so the charts come out correct. This is what the "adjust historical data" question is asking, whether you want to adjust the historical data, it really should be done automatically, as I don't know under what circumstances you wouldn't want to adjust the historical data, but as I said this code was written long ago.

Anatoly:

I had another recent Split, and that reminded me of the long-existing issue with Splits a) changing "Total Cost" if such Split causes the new (adjusted) per-Share Purchase Price to exceed 4 Decimals, and b ) not being able to Re-Open a Split Transaction (locked) and hence not being able to read any extensive Comments in there.

Can you kindly share your thoughts of any potential Downsides of 2 alternate Ways of Recording a Split as follows (assume Number New Shares > Number of Old Shares):

EXAMPLE OF ISSUE:
Originally buy 70 shares @ 71.07 = 4,974.90 Total Cost.
NOW 8:1 Split:
With maximum Rounding precision, PSM will show:
560 shares x 8.8838 per Share = 4,974.928 Total Cost --> a Total Cost DEVIATION of 2.8 cents from correct number due to Split.

ALTERNATIVE A: Use "BUY" transaction type instead of 8:1 Split:
Buy 490 Shares @ 0.00 (zero) = zero Total Cost.
Result: Total Cost for Position UNCHANGED. Number Shares adjusted for Split.
DOWNSIDE: AVERAGE AGE goes down as it treats the 490 shares as a real Purchase.

ALTERNATIVE B: Use "REINV. DIV" transaction type instead of 8:1 Split:
Reinv. 490 Shares @ 0.00 (zero) = zero Total Cost.
SAME RESULT as ALTERNATIVE A, with same Average Age Issue.

Anatoly, do you see any other Downside besides the "Average Age" issue? The advantage, of course, is that Total Cost remains correct, and that the issue with not being able to re-open Split Transaction and read extensive Notes is addressed.

Any concerns where this messes up other things in any other calcs -- now or later?

And if A and B work, would this potentially be the basis for fundamentally re-defining and replacing how the "Split" transaction works in PSM ... especially if you could in that case somehow ensure that Avg. Age does not get changed somehow?

Thanks for your thoughts on this.

If you don't want to mess up the average age, set the date of the buy transaction the same as the original transaction. But it probably doesn't matter. Using a buy transaction at zero cost should work fine.