Version: 3.98.0 (using KDE 4.4.2) Compiler: install claydoh package OS: Linux Installed from: Ubuntu Packages I have about 2 dozen scheduled transactions, all but one appear to be behaving normally. I have one that recurs every three days and it is showing as duplicated in the register of the account from which the withdrawal happens. That is, 2 are being shown every three days. The calculation for the projected balance is including both instances of the transaction. The transaction is set to move to the next processing day if it falls on a non-processing date, I have deleted the original transaction, saved the file and recreated the transaction and it was still duplicated. But after upping the projecting to 30 days, I see that only the first few instances are duplicated, then they appear once on the scheduled date,
Does the forecast view show the same problem? That would help us pinpoint the problem, because the calculation methods are similar, but not exactly the same.
I don't see the details in the forecast (at least I don't know how to show the details) but the incorrect projected balances match so I would say yes. Thanks, great application by the way. Warren G. Schaub On Mon, 2010-05-24 at 16:54 +0200, Alvaro Soliverez wrote: > https://bugs.kde.org/show_bug.cgi?id=238583 > > > > > > --- Comment #1 from Alvaro Soliverez <asoliverez gmail com> 2010-05-24 16:54:16 --- > Does the forecast view show the same problem? That would help us pinpoint the > problem, because the calculation methods are similar, but not exactly the same. >
I can only see this in one case, where a holiday on Monday causes a transaction to move from Saturday to Thursday, and then it overlaps with the next occurrence. Is this perhaps what you see? Otherwise, it would help if you can save your file as anonymous file, compress it and attach it here. Thanks!
The scenario you describe exists for May 24 & May 26. But it shows duplicate transactions for June 1, but no duplicates after that. Thanks. Warren G. Schaub On Tue, 2010-05-25 at 03:25 +0200, Alvaro Soliverez wrote: > https://bugs.kde.org/show_bug.cgi?id=238583 > > > > > > --- Comment #3 from Alvaro Soliverez <asoliverez gmail com> 2010-05-25 03:25:30 --- > I can only see this in one case, where a holiday on Monday causes a transaction > to move from Saturday to Thursday, and then it overlaps with the next > occurrence. Is this perhaps what you see? > > Otherwise, it would help if you can save your file as anonymous file, compress > it and attach it here. > > Thanks! >
I cannot reproduce your issue, so are you able to test the patch in Bug 238937? Thanks
Or attaching an anonymized file. For that, you go to Save As, select the format "Anonymous file" and save. That will strip off any personal data of the file while keeping the data we need to reproduce the issue. Then, zip the file and attach it here, please.
Created attachment 43958 [details] Anonymous file Sorry, I thought I had uploaded this already. My mistake.
I've looked at your file and for scheduled transaction SCH000053 due on 23rd May and then every 3 days. This gives dates of 23rd, 26th, 29th, 1st, 4th, etc. Looking at the ledger I see the first 2 transactions showing as late on 28th, the one from 29th (a Saturday) gets moved 1st (due to the weekend and Monday also being a holiday) and then you have the scheduled one for 1st too. So in short, everything looks correct.
Created attachment 47409 [details] Showing scheduled transactions in register
I had been seeing two transactions for June 1, now I am seeing one for June 1 and a second for June 2.
Could you run a consistency check (under Tools menu) and then see if you still have the issue. 3.98.1 should also be available, is that available to you from Ubuntu? If so could you also test against that version. Thanks.
Ran consistency check, no change. I see only 3.98.0 on Source Forge. Bear in mind, if it isn't apparent, you are dealing with a newbie. I can give compiling 3.98.1 a try if I can get a file and had instructions. Thanks for your help.
Never mind. Neither an update or a consistency check will help in this situation, at least for the time being. Here is my analysis of the situation: you have a 3-day schedule, set to move to mondays if it occurrs in non-business day. KMyMoney calculates the occurrences every 3-day. It then evaluates the result of the calculation and moves the resulting date to Mondays, if necessary. It won't check if there is another occurrence that same day or the next. What I think you expect is, if an occurrence is moved to Monday, then the next occurrence should be on Thursday. Is that correct?
Precisely, that is what I thought would happen. Your analysis is spot on.
Ok. Great that we have finally reached an understanding. At the time, KMyMoney does not work this way. It is designed to work on fixed occurrences, and adjust the dates after the fact, not for this kind of "fluid" schedule. Ian can provide more info on whether it would be feasible to implement such feature. Without messing so much with the current implementation, that is.
So that I can get this clear, are you looking for a schedule that: a) happens every 3 processing days; b) happens every 3 days but if it lands on a non-processing day, it and any subsequent payments are shifted on; c) happens every 3 days but if it lands on a non-processing day, that payment gets skipped.
A - Correct B - Correct C - Not necessary Maybe my scenario would help explain: My commute to work is an unusually long drive, about 100 miles round trip. So, I refuel the car every three work (or processing) days. What I am attempting to do is project the account's balance with the refueling costs that happen every three work days, So, if the refueling date would fall on a non-processing day it would be moved to the next processing date and subsequent transactions adjusted accordingly. I'm one of the converts from MS Money (I did not have these transactions scheduled in MS Money) but I can check if MS Money did it as I would expect. Not that I would ask for anyone to model their product on what Microsoft does! ;-) Thanks again for your work on this.
Thanks for your input, Warren. At this point we are sure it is not a bug, so I'm changing this to wishlist, and we can review whether we implement a new feature based on this.
Revising bug summary to reflect nature of enhancement
Enhancement requested over 5 years ago and add to wishlist.