SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Perform reconciliation 2. Note report that account total and total of reconciled transactions equal one another 3. Respond to query box saying they are not equal OBSERVED RESULT query box says the two totals are unequal EXPECTED RESULT the two totals are equal SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy ADDITIONAL INFORMATION
Please provide the exact wording of that message. I believe I have seen it myself, and have just ignored it. If we are going to track down what actually triggers it, we need the exact wording of the message, to find where in the code it is triggered and what data situation would cause it. It would be great to have a sample data file that exhibits the error, but I suspect that would take an unreasonable effort to create, and anonymizing a real data file changes the values of transactions, so I doubt that would work.
Thanks for your help. Here;s the wording: You are about to finish the reconciliation of this account with a difference between your bank statement and the transactions marked as cleared. Are you sure you want to finish the reconciliation? The problem seems to be unique to the only account that I regularly reconcile (checking account). I did a sample reconciliation on another account and did not encounter the problem. It could be the checking account has an entry that doesn't show up in the leger, because of a data error or something like that. My setup: KMyMoney 5.2.1 April 2022 Operating System: Ubuntu 22.04.1 LTS Kernel: Linux 5.15.0-46-generic Architecture: x86-64 Hardware Vendor: Dell Inc. Hardware Model: OptiPlex XE2 On Sun, Aug 21, 2022 at 5:52 PM Jack <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=458152 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #1 from Jack <ostroffjh@users.sourceforge.net> --- > Please provide the exact wording of that message. I believe I have seen it > myself, and have just ignored it. If we are going to track down what actually > triggers it, we need the exact wording of the message, to find where in the > code it is triggered and what data situation would cause it. It would be great > to have a sample data file that exhibits the error, but I suspect that would > take an unreasonable effort to create, and anonymizing a real data file changes > the values of transactions, so I doubt that would work. > > -- > You are receiving this mail because: > You reported the bug.
Adjusting status. Probably low priority, but worth tracking down why the system thinks the two amounts are different.
I changed the title to a more meaningful description and so that it fits on one line. Here's a copy of original title: A question box pops up at close of reconciliation requesting that user "confirm end of reconciliation". The text says the account and the reconciled transactions differ when in fact the account and the reconciled transactions are equal.
The only thing I could think of is a rounding problem. Since you are on a Linux system, can you take the script at https://invent.kde.org/office/kmymoney/-/blob/master/contrib/getsplitpart.pl and check if you can identify such a rounding problem? If you don't know howto use that script, please get back to us. And please, if you respond via mail cut off the original text below your input because it ruins the view onto the bug (see https://bugs.kde.org/show_bug.cgi?id=458152#c2). Thank you.
Forgot to adjust state
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Thomas Baumgart from comment #5) > The only thing I could think of is a rounding problem. Since you are on a > Linux system, can you take the script at > https://invent.kde.org/office/kmymoney/-/blob/master/contrib/getsplitpart.pl > and check if you can identify such a rounding problem? If you don't know > howto use that script, please get back to us. And please, if you respond via > mail cut off the original text below your input because it ruins the view > onto the bug (see https://bugs.kde.org/show_bug.cgi?id=458152#c2). Thank you. Thank you for your patience and your help. I apologize for not responding earlier. I ran getsplitpart.pl. The output.csv file contains 51 lines with dates from 1990 to 2018. There are 35 with SplitId S0001 and the rest with S0002. When I copied the file into this comment I received a spam rejection notice. --Jeff
I don't think the split number matters. I have only a vague memory of dealing with a similar problem some time age. Pending another response from Thomas, what I would suggest, after making a backup of your data file, is to edit and save each of those transactions, paying close attention that the value of the transaction does not change. There have been changes since 2018 which correct some of the rounding issues which can cause such problems. Once you do that, save the file and run the Perl script again to see if the output changes. When you reply, you can change the status back to REPORTED, to keep the Bug Janitor quiet.
(In reply to Jack from comment #9) > I don't think the split number matters. I have only a vague memory of > dealing with a similar problem some time age. Pending another response from > Thomas, what I would suggest, after making a backup of your data file, is to > edit and save each of those transactions, paying close attention that the > value of the transaction does not change. There have been changes since > 2018 which correct some of the rounding issues which can cause such > problems. Once you do that, save the file and run the Perl script again to > see if the output changes. > > When you reply, you can change the status back to REPORTED, to keep the Bug > Janitor quiet. I'll do that. Thanks. Jeff
Please, if you respond via mail cut off the original text below your input because it ruins the view onto the bug tracker (see https://bugs.kde.org/show_bug.cgi?id=458152#c2). Thank you. Having multiple splits with the same ID is not a problem here, since each of them belongs to their own transaction. What is more important is the sum of the splits 'shares' and 'value' field of all of them. Does the result have more than 2 digits in the fraction? I assume your currency is based on 100 units. If so, look out for the split/transaction that is causing it.
(In reply to Thomas Baumgart from comment #11) > Please, if you respond via mail cut off the original text below your input > because it ruins the view onto the bug tracker (see > https://bugs.kde.org/show_bug.cgi?id=458152#c2). Thank you. > > Having multiple splits with the same ID is not a problem here, since each of > them belongs to their own transaction. What is more important is the sum of > the splits 'shares' and 'value' field of all of them. Does the result have > more than 2 digits in the fraction? I assume your currency is based on 100 > units. If so, look out for the split/transaction that is causing it. Thank you. I will check and report. -- Jeff
Thanks, again. To begin with, I used the procedure that Jack suggested. Most of the entries in the output.csv file are dated at the time I started using KMM. Of the others, in general, the entries for cash accounts listed in the output.csv file are opening balances. The entries for securities are a mix of purchases and splits. I took Jack's advice and added a comment in the memo field of all the entries and then saved them. When I saved the entries for the securities accounts I mostly received an "Exchange Rate Price Error" when I saved them. The exchange correction is given as "Currency USD" to [name of account]. There is an option (already selected) to "Update Price History" which I have been accepting. All the transactions, whether cash or securities, had the same dollar amounts when I saved them as they had when I opened them. After completing that task, I checked to see whether any securities transactions or splits involved amounts with more than two places beyond the decimal point. I found none that did so. I should point out that the problem I encountered occurred in only one account: my checking account. I have not been reconciling any other accounts. -- Jeff
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!