In release 3.8 a scheduled transaction for a stock dividend that includes a split line in the security account for reference with no shares traded now asks for a price in the SLR. Expected: Since there are no shares traded, The SLR should not ask for a price that the user may not know. In release 2.6.19 it did not ask for a price.
What are the formulae in the SX credit and debit fields?
Created attachment 373857 [details] This three line SX triggers the price dialog
Ah, got it. The linking split triggers the price request to convert 0 shares into USD. Out of curiosity will the SX editor let you leave that blank instead of putting 0 in it, and if it does, does it make a difference?
I need to go to a backup before I scheduled it, because I do not remember what I did. Give me a few more minutes.
Oh, it required a value to allow SLR to continue. On my first try I entered zero and it appeared ok from the created transactions register. Then I tried entering 1 and it still appeared ok from the created transactions register, but then I jumped to the security register and found the price 1.0000 in every transaction split line that had zero shares, including lines for other share accounts in transactions that had multiple share accounts. I forgot to do that after trying zero price.
I guess I had not noticed the price of 1 in release 2.6.19 security register zero share split lines. there it does not have the four fractional share decimals. After entering zero I went to that transaction in the created transaction register and jumped to the security account. Again, every zero share security account split line has a price of 1.0000, even if the highlight is in the description box. The price 1.0000 also appears in other transactions with zero shares except for sale transaction unrealized gain adjustment lines that have a blank in the no of shares box show blank in the register.
I have now tested this bug in release 4.4 in Windows 10 and found that it still exists. There is a new issue with (need Value) box floating away from it's anchor SX in the SLR, but that is unrelated to this bug, however it is a major annoyance. In answer to comment 1, there are no variables, and just a few numeric values in the debit and credit boxes similar to the attachment. no values in shares. In answer to Comment 3, I cannot leave the box blank, the SLR will return and ask again for a number. However, it will accept either zero or one as an entry. The resulting transaction seems to be the same after either number is entered, but the price value appears as 1.0000 when the preference is set to force prices to decimal. Further, when in he security register I am 'not allowed to edit the exchange rate', bur when in the brokerage register 'there is no need to edit the exchange rate as the transaction is balanced' Finally, it appears that similar transactions that do result in a reinvestment purchase of additional shares do not create a corresponding entry in the price database as a manual transaction entry would. If you have additional questions please ask.
I have a corollary to add which I am not sure is covered in another bug report. A stock purchase scheduled transaction which correctly requests a price is subsequently created with a price of 1.0 instead of the price entered in the SLR dialog. This seems to be limited to SX's created in release 3.8 or 3.x, as older SX's are not affected.
That purchase price problem is not rigorously tested. It may apply to all security purchase transactions committed in 3.8
More information. Now that a couple of older re-investment transactions have triggered, they correctly applied the SLR generated price to the stock purchases. Scheduled transactions created in release 3.8 apply a price of 1 regardless of the price entered by the SLR wizard.
(In reply to David Carlson from comment #10) > More information. Now that a couple of older re-investment transactions > have triggered, they correctly applied the SLR generated price to the stock > purchases. Scheduled transactions created in release 3.8 apply a price of 1 > regardless of the price entered by the SLR wizard. Can copy-and-paste the XML of one of the SXes that worked right and one that didn't from your file?
I am attempting to copy and paste but so far I am laboring with Microsoft Wordpad which does not want to have more than one document open at a time and Open Office Writer which is still trying to open the 100,000 Kbytes plus XML file. The meat of the transactions seems to be buried under guids so I think that I need to copy them too.
Try Notepad instead of Wordpad. It will probably work better anyway, it's designed for plain text and Wordpad is for RTF. Writer will probably fail to open it, it's native file formats (ODT and DOCX) are XML too and it's trying to make sense of GnuCash's XML. If Notepad won't do it get https://code.visualstudio.com or http://notepad-plus-plus.org. Don't worry about the GUIDs for now, they're useful anonymizers for the data.
Created attachment 374050 [details] Two SX's XML I was trying to use LibreOffice. It finally opened the file and searching for one of the guids led me to some XML that I am not sure where to start and end the selection as it seems to be multiple slots, some with additional guids. If we need to get into those I will need more help.
Yeah, I need to see the template transactions too. The linkage is a bit weird: The GUID in <sx:templ-acct type="guid">8356acb11d23413eaf3125207b325f1f</sx:templ-acct> matches <split:account type="guid">8356acb11d23413eaf3125207b325f1f</split:account> in the template transaction. The template transactions are in <gnc:template-transactions> just above <gnc:schedaction>
Created attachment 374051 [details] Cherry Picked segments from data file I hope that I was able to pick the segments that contain the information that you need. this prints on 8 sheets of paper. the first four sheets are from the bad SX, the last four sheets are from a similar older SX that works correctly when triggered in the SLR. BTW, I like notepad++ a lot better for this task than the other editors.
Comment on attachment 374051 [details] Cherry Picked segments from data file What are the account types and commodities of account fdb3f9b907a34c4e9d37a5299419a10a (the good one) and account 443d4cc7211142a1ba9db6bece048f21 (the failed one) ? Can you attach a real transaction created by each of the template transactions?
The GnuCash register's habit of inserting a price of 1 when the amount is 0 has been there for as long as I've used GnuCash, which is closing in on 20 years. It's part of the same code that pops up the dialog asking you which of amount, price, and value you want GnuCash to recalculate. It's always been a bit of a PITA when trying to enter or edit cap gains splits, you have to keep deleting the shares and price fields to get the cash-only split to register. I suspect that the SX refusing to accept blank has something to do with the original issue in this bug. Failing to apply the price from the SLR is another matter.
> Failing to apply the price from the SLR is another matter. That I found and fixed. Some idiot (me) did a refactor a few years ago and got the order of the commodities backwards, so the SLR was creating a hash key "FIKMX -> USD" and the split-creation code trying to find "USD -> FIKMX". Obviously that didn't work so it used the default price of 1. Simple enough for newly-created SXes. Doesn't begin to explain why it worked OK on older ones and suggests that the obvious fix will break those.
Never mind, I think I figured it out. Please try with tomorrow's nightly. BTW the first part is a regression of bug 754192.
Created attachment 374052 [details] XML of selected account descriptions Dell has returned my wife's computer and it appears to be fixed this time so I will be able to test a version 4point whatever (Windows) nightly build on that machine. I will have to figure out if there are any bad SX's in the test file on that machine, so it may still take a while to get meaningful results.
Comment on attachment 374052 [details] XML of selected account descriptions Thanks. I think the actual variable is what got selected as the transaction currency and in which direction the internal name was constructed in two different functions. My change makes the two functions use the same code instead of different code that was supposed to do the same thing but didn't.
