[kmymoney4] [Bug 383266] Unrelated categories in report configuration for net worth
https://bugs.kde.org/show_bug.cgi?id=383266 --- Comment #1 from Ralf Habacker --- Created attachment 107145 --> https://bugs.kde.org/attachment.cgi?id=107145&action=edit test case -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383266] New: Unrelated categories in report configuration for net worth
https://bugs.kde.org/show_bug.cgi?id=383266 Bug ID: 383266 Summary: Unrelated categories in report configuration for net worth Product: kmymoney4 Version: 4.8.0 Platform: Other OS: All Status: UNCONFIRMED Severity: normal Priority: NOR Component: reports Assignee: kmymoney-devel@kde.org Reporter: ralf.habac...@freenet.de Target Milestone: --- Net worth charts only depends on assets and liabilities (see https://en.wikipedia.org/wiki/Net_worth) but in the report configuration dialog there is a tab "categories" including selectable categories which are unrelated to this report. Selecting/deselecting any of the category does not have any effect which waste time of users by trying to deal with this non functional categories and kmymoney maintainers because of obsolate bug reports. How to reproduce: 1. download appended kmymoney file 2. start kmymoney and load the file from 1. 3. open report "net worth graph" 4. select configuration 5. select tab "categories" What happens ? There are nonfunctional selectable categories displayed What is expected ? The categories tab should be hided if it is unrelated for the report -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 377368] KMyMoney 4.8 failed to import discover card ofx
https://bugs.kde.org/show_bug.cgi?id=377368 Thomas Baumgart changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #7 from Thomas Baumgart --- George, you forgot 3) get the developers for the bank's backend system to read and understand the RFC and fix the problem (hey, after all they introduced it) though your solution to 'stop using the card' on a wide scale may have some impact (I have dreaming mode on while I write this) and would be my choice as well. As to 1) why should there be an option to control the order if that is not required by the standard and 2) only if said bank pays me so that I can retire immediately and take care of KMyMoney fulltime. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 377368] KMyMoney 4.8 failed to import discover card ofx
https://bugs.kde.org/show_bug.cgi?id=377368 --- Comment #6 from geo...@wildturkeyranch.net --- Looks like two choices to me: 1) Get the folks who's code your using to give you a fix, possibly an addition option to order the header, or 2) Grab/purloin/etc. said code, fix the issue and make that part of Kmymoney. To me, the problem is the solution is dead in the water, and, for me, has caused me to stop using the card. -- You are receiving this mail because: You are the assignee for the bug.
Re: Compile Error - Fedora 26
I created a diff file and copied the text on the page in the link that you sent me to the diff file. I tried to apply it to the source and got the following errors: error: patch failed: kmymoney/mymoney/CMakeLists.txt:28 error: kmymoney/mymoney/CMakeLists.txt: patch does not apply error: kmymoney/mymoney/storage/tests/CMakeLists.txt: No such file or directory error: kmymoney/mymoney/tests/CMakeLists.txt: No such file or directory I've always downloaded a diff file in the past so I'm not sure I'm doing this correctly since I do not see anyway to download the diff file. I probably need so help applying the diff. Brendan Coupe On Mon, Aug 7, 2017 at 12:51 PM, Łukasz Wojniłowicz wrote: > Try to apply > https://cgit.kde.org/kmymoney.git/commit/? > id=747762d138682be9abbe7307680013cd643da8cb > on 4.8 branch. > > Dnia poniedziałek, 7 sierpnia 2017 18:28:15 CEST Brendan Coupe pisze: >> I have been compiling KMM from source for many years. I have been using the >> 4.8 branch recently. >> >> I upgraded from Fedora 25 to Fedora 26 a couple of weeks ago. Compiling >> fails pretty early in the process. See the last part of the output below. >> It compiled from source without any issues prior to the OS upgrade. >> >> Any idea what is going wrong? >> >> === >> *Generating MOC source EWIEGA46WW/moc_lendborrowwizardpage.cppGenerating >> MOC source JKU67JSAFJ/moc_KDChartTernaryPointDiagram.cppGenerating MOC >> source EWIEGA46WW/moc_loanamountwizardpage.cppGenerating MOC compilation >> mocs_compilation.cpp[ 6%] Built target kmm_kdchart_autogenGenerating MOC >> source EWIEGA46WW/moc_loanattributeswizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_namewizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_newcalculateloanwizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_newgeneralinfowizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_newintrowizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_newpaymentswizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_paymenteditwizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_paymentfrequencywizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_paymentwizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_previouspaymentswizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_recordpaymentwizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_schedulewizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_summaryeditwizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_summarywizardpage.cppGenerating MOC source >> EWIEGA46WW/moc_variableinterestdatewizardpage.cppGenerating MOC compilation >> mocs_compilation.cpp[ 6%] Built target newloanwizard_autogenmake: *** >> [Makefile:163: all] Error 2* >> **=== >> >> *Thanks,* >> ** >> >> *Brendan Coupe* > >
Re: Compile Error - Fedora 26
I already tried the libalkimia trick and it did not work this time. I was running with -j 8. I tried -j 1 and it took a lot longer to fail. I added -d to -j 1 and it also failed. I've copied the last part of the output below (I switched GMail to plain text mode, I hope it works). == Updating goal targets Considering target file 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen.dir/build'. File 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen.dir/build' does not exist. Considering target file 'settings_autogen'. File 'settings_autogen' does not exist. Considering target file 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen'. File 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen' does not exist. Considering target file 'kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h'. File 'kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h' does not exist. Considering target file '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui'. Looking for an implicit rule for '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui'. Trying pattern rule with stem 'ksettingsreportsdecl.ui'. Trying implicit prerequisite '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui,v'. Trying pattern rule with stem 'ksettingsreportsdecl.ui'. Trying implicit prerequisite '../kmymoney/dialogs/settings/RCS/ksettingsreportsdecl.ui,v'. Trying pattern rule with stem 'ksettingsreportsdecl.ui'. Trying implicit prerequisite '../kmymoney/dialogs/settings/RCS/ksettingsreportsdecl.ui'. Trying pattern rule with stem 'ksettingsreportsdecl.ui'. Trying implicit prerequisite '../kmymoney/dialogs/settings/s.ksettingsreportsdecl.ui'. Trying pattern rule with stem 'ksettingsreportsdecl.ui'. Trying implicit prerequisite '../kmymoney/dialogs/settings/SCCS/s.ksettingsreportsdecl.ui'. No implicit rule found for '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui'. Finished prerequisites of target file '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui'. No need to remake target '../kmymoney/dialogs/settings/ksettingsreportsdecl.ui'. Finished prerequisites of target file 'kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h'. Must remake target 'kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h'. Putting child 0x5650981b3250 (kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h) PID 25150 on the chain. Live child 0x5650981b3250 (kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h) PID 25150 [ 40%] Generating ui_ksettingsreportsdecl.h Reaping winning child 0x5650981b3250 PID 25150 Live child 0x5650981b3250 (kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h) PID 25151 Reaping winning child 0x5650981b3250 PID 25151 Removing child 0x5650981b3250 PID 25151 from chain. Successfully remade target file 'kmymoney/dialogs/settings/ui_ksettingsreportsdecl.h'. Considering target file '//kmymoneysettings.h'. File '//kmymoneysettings.h' does not exist. Looking for an implicit rule for '//kmymoneysettings.h'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//kmymoneysettings.h,v'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//RCS/kmymoneysettings.h,v'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//RCS/kmymoneysettings.h'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//s.kmymoneysettings.h'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//SCCS/s.kmymoneysettings.h'. No implicit rule found for '//kmymoneysettings.h'. Finished prerequisites of target file '//kmymoneysettings.h'. Must remake target '//kmymoneysettings.h'. make[2]: *** No rule to make target '//kmymoneysettings.h', needed by 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen'. Stop. make[1]: *** [CMakeFiles/Makefile2:6746: kmymoney/dialogs/settings/CMakeFiles/settings_autogen.dir/all] Error 2 Reaping losing child 0x55f623a17eb0 PID 25149 Removing child 0x55f623a17eb0 PID 25149 from chain. Reaping losing child 0x562b4a7e71d0 PID 20578 make: *** [Makefile:163: all] Error 2 Removing child 0x562b4a7e71d0 PID 20578 from chain. = Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//kmymoneysettings.h,v'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//RCS/kmymoneysettings.h,v'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//RCS/kmymoneysettings.h'. Trying pattern rule with stem 'kmymoneysettings.h'. Trying implicit prerequisite '//s.kmymoneysettings.h'. Trying
[kmymoney4] [Bug 377368] KMyMoney 4.8 failed to import discover card ofx
https://bugs.kde.org/show_bug.cgi?id=377368 --- Comment #5 from Jack --- George - do you have a suggestion as to who needs to act? The comments above indicate there is absolutely nothing within the KMyMoney code which can help. Thomas - is there any point in trying to bring in the KIO developers, at least to ask if there is anything they can do? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 377368] KMyMoney 4.8 failed to import discover card ofx
https://bugs.kde.org/show_bug.cgi?id=377368 --- Comment #4 from geo...@wildturkeyranch.net --- I too have this problem. The comments above seem to indicate that it is, in fact, a problem (even if it is not a bug as suggested above). What does it take to get some action here? -- You are receiving this mail because: You are the assignee for the bug.
Re: Compile Error - Fedora 26
Try to apply https://cgit.kde.org/kmymoney.git/commit/? id=747762d138682be9abbe7307680013cd643da8cb on 4.8 branch. Dnia poniedziałek, 7 sierpnia 2017 18:28:15 CEST Brendan Coupe pisze: > I have been compiling KMM from source for many years. I have been using the > 4.8 branch recently. > > I upgraded from Fedora 25 to Fedora 26 a couple of weeks ago. Compiling > fails pretty early in the process. See the last part of the output below. > It compiled from source without any issues prior to the OS upgrade. > > Any idea what is going wrong? > > === > *Generating MOC source EWIEGA46WW/moc_lendborrowwizardpage.cppGenerating > MOC source JKU67JSAFJ/moc_KDChartTernaryPointDiagram.cppGenerating MOC > source EWIEGA46WW/moc_loanamountwizardpage.cppGenerating MOC compilation > mocs_compilation.cpp[ 6%] Built target kmm_kdchart_autogenGenerating MOC > source EWIEGA46WW/moc_loanattributeswizardpage.cppGenerating MOC source > EWIEGA46WW/moc_namewizardpage.cppGenerating MOC source > EWIEGA46WW/moc_newcalculateloanwizardpage.cppGenerating MOC source > EWIEGA46WW/moc_newgeneralinfowizardpage.cppGenerating MOC source > EWIEGA46WW/moc_newintrowizardpage.cppGenerating MOC source > EWIEGA46WW/moc_newpaymentswizardpage.cppGenerating MOC source > EWIEGA46WW/moc_paymenteditwizardpage.cppGenerating MOC source > EWIEGA46WW/moc_paymentfrequencywizardpage.cppGenerating MOC source > EWIEGA46WW/moc_paymentwizardpage.cppGenerating MOC source > EWIEGA46WW/moc_previouspaymentswizardpage.cppGenerating MOC source > EWIEGA46WW/moc_recordpaymentwizardpage.cppGenerating MOC source > EWIEGA46WW/moc_schedulewizardpage.cppGenerating MOC source > EWIEGA46WW/moc_summaryeditwizardpage.cppGenerating MOC source > EWIEGA46WW/moc_summarywizardpage.cppGenerating MOC source > EWIEGA46WW/moc_variableinterestdatewizardpage.cppGenerating MOC compilation > mocs_compilation.cpp[ 6%] Built target newloanwizard_autogenmake: *** > [Makefile:163: all] Error 2* > **=== > > *Thanks,* > ** > > *Brendan Coupe*
[kmymoney4] [Bug 383239] Automatic VAT split causes offset due to rounding error
https://bugs.kde.org/show_bug.cgi?id=383239 Thomas Baumgart changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://commits.kde.org/kmy ||money/eb7e02dd0fc840fa44d5a ||d1d514060d9637468f7 Status|CONFIRMED |RESOLVED Version Fixed In||5.0 --- Comment #2 from Thomas Baumgart --- Git commit eb7e02dd0fc840fa44d5ad1d514060d9637468f7 by Thomas Baumgart. Committed on 07/08/2017 at 18:15. Pushed by tbaumgart into branch 'master'. Fix VAT assignment rounding problems Rounding problems led to non-balanced transactions. This change avoids such a situation. FIXED-IN: 5.0 CCMAIL: geebackho...@gmail.com M +3-3kmymoney/mymoney/mymoneyfile.cpp https://commits.kde.org/kmymoney/eb7e02dd0fc840fa44d5ad1d514060d9637468f7 -- You are receiving this mail because: You are the assignee for the bug.
Re: Compile Error - Fedora 26
Hello Brendan, On 2017.08.07 12:28, Brendan Coupe wrote: I have been compiling KMM from source for many years. I have been using the 4.8 branch recently. I upgraded from Fedora 25 to Fedora 26 a couple of weeks ago. Compiling fails pretty early in the process. See the last part of the output below. It compiled from source without any issues prior to the OS upgrade. Any idea what is going wrong? === *Generating MOC source EWIEGA46WW/moc_lendborrowwizardpage.cppGenerating MOC source JKU67JSAFJ/moc_KDChartTernaryPointDiagram.cppGenerating MOC source EWIEGA46WW/moc_loanamountwizardpage.cppGenerating MOC compilation mocs_compilation.cpp[ 6%] Built target kmm_kdchart_autogenGenerating MOC source EWIEGA46WW/moc_loanattributeswizardpage.cppGenerating MOC source EWIEGA46WW/moc_namewizardpage.cppGenerating MOC source EWIEGA46WW/moc_newcalculateloanwizardpage.cppGenerating MOC source EWIEGA46WW/moc_newgeneralinfowizardpage.cppGenerating MOC source EWIEGA46WW/moc_newintrowizardpage.cppGenerating MOC source EWIEGA46WW/moc_newpaymentswizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymenteditwizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymentfrequencywizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymentwizardpage.cppGenerating MOC source EWIEGA46WW/moc_previouspaymentswizardpage.cppGenerating MOC source EWIEGA46WW/moc_recordpaymentwizardpage.cppGenerating MOC source EWIEGA46WW/moc_schedulewizardpage.cppGenerating MOC source EWIEGA46WW/moc_summaryeditwizardpage.cppGenerating MOC source EWIEGA46WW/moc_summarywizardpage.cppGenerating MOC source EWIEGA46WW/moc_variableinterestdatewizardpage.cppGenerating MOC compilation mocs_compilation.cpp[ 6%] Built target newloanwizard_autogenmake: *** [Makefile:163: all] Error 2* **=== First please consider sending plain text and not HTML to the list - you can see it messes up wrapping. This seems similar to a problem you had last October. Have you tried "make -d" (or some slightly less verbose variant) to get debugging info? What -j value are you using? I believe at that time, make (or gcc?) couldn't find some header file, which you fixed by removing and reinstalling libalkimia. Jack
Compile Error - Fedora 26
I have been compiling KMM from source for many years. I have been using the 4.8 branch recently. I upgraded from Fedora 25 to Fedora 26 a couple of weeks ago. Compiling fails pretty early in the process. See the last part of the output below. It compiled from source without any issues prior to the OS upgrade. Any idea what is going wrong? === *Generating MOC source EWIEGA46WW/moc_lendborrowwizardpage.cppGenerating MOC source JKU67JSAFJ/moc_KDChartTernaryPointDiagram.cppGenerating MOC source EWIEGA46WW/moc_loanamountwizardpage.cppGenerating MOC compilation mocs_compilation.cpp[ 6%] Built target kmm_kdchart_autogenGenerating MOC source EWIEGA46WW/moc_loanattributeswizardpage.cppGenerating MOC source EWIEGA46WW/moc_namewizardpage.cppGenerating MOC source EWIEGA46WW/moc_newcalculateloanwizardpage.cppGenerating MOC source EWIEGA46WW/moc_newgeneralinfowizardpage.cppGenerating MOC source EWIEGA46WW/moc_newintrowizardpage.cppGenerating MOC source EWIEGA46WW/moc_newpaymentswizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymenteditwizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymentfrequencywizardpage.cppGenerating MOC source EWIEGA46WW/moc_paymentwizardpage.cppGenerating MOC source EWIEGA46WW/moc_previouspaymentswizardpage.cppGenerating MOC source EWIEGA46WW/moc_recordpaymentwizardpage.cppGenerating MOC source EWIEGA46WW/moc_schedulewizardpage.cppGenerating MOC source EWIEGA46WW/moc_summaryeditwizardpage.cppGenerating MOC source EWIEGA46WW/moc_summarywizardpage.cppGenerating MOC source EWIEGA46WW/moc_variableinterestdatewizardpage.cppGenerating MOC compilation mocs_compilation.cpp[ 6%] Built target newloanwizard_autogenmake: *** [Makefile:163: all] Error 2* **=== *Thanks,* ** *Brendan Coupe*
Re: Rounding Error with Taxes
Hi Gee Backhouse, On Montag, 7. August 2017 16:56:36 CEST you wrote: > Thank you for taking the time to reply, I really appreciate it. > I understand rounding methods but I don't understand why Kmymoney is fixed > on rounding the numbers down in this scenario. > Having entered the gross figure of 17.07 I don't mind whether Kmymoney > chooses 14.23 + 2.84 or 14.22 + 2.85 since both options add up to 17.07. > The problem I'm facing is that it chooses 14.22 + 2.84 giving a total of > 17.06 which conflicts with the gross figure I entered - and it adds a > yellow warning triangle to the transaction too! Yes, understood. The problem stems from the internal calculation of the tax part. It is always calculated by subtracting the net value from the gross value. The problem is, that it does not adjust the net value to the rounded one before doing the subtraction. This in fact leaves the tax part as 2.855 in your example which is then rounded again. It should round 14.225 to 14.22 and then doing the subtraction to 17.07-14.22 which results in 2.85 and everyone is happy. Hey, you found a bug! And a rather old one: it lives there for more than 10 years now. Congrats. I opened https://bugs.kde.org/show_bug.cgi?id=383239 and attached your screenshot. Sorry for the spelling error in your name: I used the German version of house :( > I really want to use the functionality there because entering the figures > manually takes too long and opens up too much room for error. However, > there's a bug somewhere. Yes, see above. > As for the version, please see the attached. We do have 4.8.0 out already (which still has your problem as it is also there in the latest and greatest development version). Just in case you want to update at some point in time. > Many thanks again, > Gee -- Regards Thomas Baumgart https://www.telegram.org/ Telegram, the better WhatsApp - To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. Scott Granneman, Security Focus - signature.asc Description: This is a digitally signed message part.
[kmymoney4] [Bug 383239] Automatic VAT split causes offset due to rounding error
https://bugs.kde.org/show_bug.cgi?id=383239 Thomas Baumgart changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #1 from Thomas Baumgart --- The problem stems from the internal calculation of the tax part. It is always calculated by subtracting the net value from the gross value. The problem is, that it does not adjust the net value to the rounded one before doing the subtraction. This in fact leaves the tax part as 2.855 in your example which is then rounded again. It should round 14.225 to 14.22 and then doing the subtraction to 17.07-14.22 which results in 2.85 and everyone is happy. Hey, you found a bug! And a rather old one: it lives there for more than 10 years now. Congrats. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383239] New: Automatic VAT split causes offset due to rounding error
https://bugs.kde.org/show_bug.cgi?id=383239 Bug ID: 383239 Summary: Automatic VAT split causes offset due to rounding error Product: kmymoney4 Version: 4.7.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: tbaumg...@kde.org Target Milestone: --- Created attachment 107126 --> https://bugs.kde.org/attachment.cgi?id=107126&action=edit Split editor showing offset of one cent Gee Backhaus reported: I am having to consider tax (VAT) for the first time in Kmymoney and have found a rounding error. I followed the excellent instructions in your pdf manual and they work like a dream until there's a number that it is unable to resolve. *Example*: I am entering the gross amount of 17.07 and the associated tax amount is 20%. On a calculator 17.07 gives 14.225 + 2.845 In Kmymoney 17.07 gives 14.22 + 2.84 (automatically as shown in the attached). So, Kmymoney appears to round each value down and leave me with a discrepancy - which I am also unable to override manually. This is on 4.7.2 but is also in current git master. -- You are receiving this mail because: You are the assignee for the bug.
Re: Rounding Error with Taxes
Hi Gee, On Montag, 7. August 2017 13:01:52 CEST Gee Backhouse wrote: > Hello, > > Firstly, thank you for a great product which I use and love. > > And now, my problem. > > I am having to consider tax (VAT) for the first time in Kmymoney and have > found a rounding error. I followed the excellent instructions in your pdf > manual and they work like a dream until there's a number that it is unable > to resolve. > > *Example*: I am entering the gross amount of 17.07 and the associated tax > amount is 20%. > On a calculator 17.07 gives 14.225 + 2.845 > In Kmymoney 17.07 gives 14.22 + 2.84 (automatically as shown in the > attached). So, Kmymoney appears to round each value down and leave me with > a discrepancy - which I am also unable to override manually. Rounding is a tricky business. There are many ways out there, how rounding can be performed. See https://www.mathsisfun.com/numbers/rounding-methods.html for a good overview. What are the values that you expect to show up? Is it 14.23 and 2.84 or 14.22 and 2.85? The method we currently use on the net amount is documented as follows: RoundRound /**< * Use RoundHalfDown for 0.1 .. 0.4 and * RoundHalfUp for 0.6 .. 0.9. Use RoundHalfUp * for 0.5 in case the resulting numerator * is odd, RoundHalfDown in case the resulting * numerator is even. * e.g. 0.5 -> 0.0 and 1.5 -> 2.0 */ I am using the feature myself extensively and never had these problems. OK, my VAT percentage is 19% so that seems to give odd numbers to not run into this scenario. > Can you help? We will try. I have no immediate solution (other as to turn off the automatic VAT assignment for now and enter values manually). I think I have localized the source of the problem and can then fix it in source. This comes to my next question: Which version of KMyMoney are you using? > Many thanks. Yours hopefully, -- Regards Thomas Baumgart https://www.telegram.org/ Telegram, the better WhatsApp - On Windoze it helps to reboot, on UNIX it helps to be root! - signature.asc Description: This is a digitally signed message part.
Rounding Error with Taxes
Hello, Firstly, thank you for a great product which I use and love. And now, my problem. I am having to consider tax (VAT) for the first time in Kmymoney and have found a rounding error. I followed the excellent instructions in your pdf manual and they work like a dream until there's a number that it is unable to resolve. *Example*: I am entering the gross amount of 17.07 and the associated tax amount is 20%. On a calculator 17.07 gives 14.225 + 2.845 In Kmymoney 17.07 gives 14.22 + 2.84 (automatically as shown in the attached). So, Kmymoney appears to round each value down and leave me with a discrepancy - which I am also unable to override manually. Can you help? Many thanks. Yours hopefully, Gee
[kmymoney4] [Bug 383165] Networth report shows wrong values
https://bugs.kde.org/show_bug.cgi?id=383165 --- Comment #7 from Ralf Habacker --- (In reply to Ralf Habacker from comment #6) > (In reply to Thomas Baumgart from comment #4) > > One needs to file it once to fix the file so we need a fix to solve > > this issue in code also. > I fixed that by open report configure dialog and press okay. I think that this issue indicates a generic problem in case the reporting engine may be extended/updated in the future and how to make sure that present reports are still working. This issue relates also to the usage of the expert mode, to which new stuff may be bound but on the other side may not work together with other features people depends on. An example is that the display of equity accounts is bound to expert mode in several locations and it might be a good idea to bound the usage of equity account in reports to bound to this flag too and let people disable expert mode to not have equity accounts in reports. But this does not work for people depending on equity accounts been enabled (see for example https://bugs.kde.org/show_bug.cgi?id=382378#c6) On the other side people may want to have a report about net worth change in this year not including opening balance, which is what the "Net worth graph (false)" report shows. If I'm incorrect about my assumptions in this statement please let me know. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383165] Networth report shows wrong values
https://bugs.kde.org/show_bug.cgi?id=383165 --- Comment #6 from Ralf Habacker --- (In reply to Thomas Baumgart from comment #4) > One needs to file it once to fix the file so we need a fix to solve > this issue in code also. I fixed that by open report configure dialog and press okay. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383165] Networth report shows wrong values
https://bugs.kde.org/show_bug.cgi?id=383165 --- Comment #5 from Ralf Habacker --- (In reply to Thomas Baumgart from comment #3) > It contains two customized reports (correct and false). > The false one is a copy of the default networth report just the name has > been adjusted. I tweaked the configuration so that the correct one shows how > the graph must appear. Ah, you added id="A04" to the correct report to limit the used accounts. + In the wrong report there is + > Ralf, can you check if the default (false) one also shows false values in > 4.8 so that we know about the status of 4.8. it is the same -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383224] New: Missing account types for generating complete balance sheets
https://bugs.kde.org/show_bug.cgi?id=383224 Bug ID: 383224 Summary: Missing account types for generating complete balance sheets Product: kmymoney4 Version: 4.8.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: reports Assignee: kmymoney-devel@kde.org Reporter: ralf.habac...@freenet.de Target Milestone: --- Created attachment 107120 --> https://bugs.kde.org/attachment.cgi?id=107120&action=edit kmymoney test file It is currently not possible to generate balance sheets containing all accounts. Balance sheets only contains account below the liability and asset top level accounts. How to reproduce ? 1. download appended kmymoney test file 2. start kymoney and load the test file 3. open "Account balances by type" What happens ? Only liability, asset and checking accounts are displayed. expense, income and equity account (and probably others) are not displayed What is expected ? It should be possible to generate a report containing all available account (ideally to be selectable from a list) Additional informations The category tab of the report configurations shows income and expense accounts and they are checked, which let me think that they should be included in the report, but they are not. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 383161] Broken net worth graph in case data contains only the same value
https://bugs.kde.org/show_bug.cgi?id=383161 --- Comment #6 from Ralf Habacker --- Git commit 6e5b5fd698aac46906e37b2ba3ac0c1e2fc5edfb by Ralf Habacker. Committed on 07/08/2017 at 08:58. Pushed by habacker into branch '4.8'. Do not use static cast to avoid crashes in case the plane does not have the expected type Thanks to Lukasz Wojnilowicz for pointing out. M +4-2kmymoney/reports/kreportchartview.cpp https://commits.kde.org/kmymoney/6e5b5fd698aac46906e37b2ba3ac0c1e2fc5edfb -- You are receiving this mail because: You are the assignee for the bug.
[kdiagram] [Bug 383160] Crash on showing investment price chart
https://bugs.kde.org/show_bug.cgi?id=383160 --- Comment #6 from Ralf Habacker --- (In reply to Ralf Habacker from comment #5) > - position.row >=0 && position.row < m_data[ 0 ].size(); > -> this checks if the requested row is in column 0, which may be wrong if On the crash I had m_data[0].size was 367 m_data[1].size was 110 position.column was 1 position.row was 110 The original codes checkes that position.row < m_data[ 0 ].size() which returns true (where it should return false) but fails later on access to m_data[1][110] with an out of index exception. -- You are receiving this mail because: You are on the CC list for the bug.
[kdiagram] [Bug 383160] Crash on showing investment price chart
https://bugs.kde.org/show_bug.cgi?id=383160 --- Comment #5 from Ralf Habacker --- (In reply to NSLW from comment #4) > (In reply to Thomas Baumgart from comment #3) it > doesn't crash for me on master branch of KMM. Thomas, can you confirm Ralf's > crash? If it does not crash it does not mean that there is no bug. See the implementation of CartesianDiagramDataCompressor::mapsToModelIndex My observations shows that m_data is constructed as following: m_data [0] column 0 [0] row 0 of column 0 [1] row 1 of column 0 [m] row m of column 0 [1] column 1 [0] row 0 of column 1 [1] row 1 of column 1 [p] row p of column 1 [n] column n [0] row 0 of column n [1] row 1 of column n [q] row q of column n return m_model && m_data.size() > 0 && m_data[ 0 ].size() > 0 && position.column >= 0 && position.column < m_data.size() && -> this checks if the requested column is in m_data - position.row >=0 && position.row < m_data[ 0 ].size(); -> this checks if the requested row is in column 0, which may be wrong if + position.row >=0 && position.row < m_data[ position.column ].size(); instead the requested row needs to be checked against m_data[position.column] -- You are receiving this mail because: You are on the CC list for the bug.
