Bug 238583 - Allow schedules to be based on processing days
Summary: Allow schedules to be based on processing days
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-23 16:19 UTC by warren_schaub
Modified: 2018-03-01 15:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Anonymous file (112.12 KB, application/x-gzip)
2010-05-28 02:31 UTC, warren_schaub
Details
Showing scheduled transactions in register (3.79 KB, image/png)
2010-05-28 03:49 UTC, warren_schaub
Details

Note You need to log in before you can comment on or make changes to this bug.
Description warren_schaub 2010-05-23 16:19:15 UTC
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,
Comment 1 Alvaro Soliverez 2010-05-24 16:54:16 UTC
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.
Comment 2 warren_schaub 2010-05-25 02:25:53 UTC
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.
>
Comment 3 Alvaro Soliverez 2010-05-25 03:25:30 UTC
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!
Comment 4 warren_schaub 2010-05-25 03:54:28 UTC
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!
>
Comment 5 Ian Neal 2010-05-27 20:18:32 UTC
I cannot reproduce your issue, so are you able to test the patch in Bug 238937?
Thanks
Comment 6 Alvaro Soliverez 2010-05-27 20:26:37 UTC
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.
Comment 7 warren_schaub 2010-05-28 02:31:15 UTC
Created attachment 43958 [details]
Anonymous file

Sorry, I thought I had uploaded this already.  My mistake.
Comment 8 Ian Neal 2010-05-28 03:30:47 UTC
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.
Comment 9 warren_schaub 2010-05-28 03:49:37 UTC
Created attachment 47409 [details]
Showing scheduled transactions in register
Comment 10 warren_schaub 2010-05-28 03:53:28 UTC
I had been seeing two transactions for June 1, now I am seeing one for June 1 and a second for June 2.
Comment 11 Ian Neal 2010-05-28 10:52:00 UTC
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.
Comment 12 warren_schaub 2010-05-28 14:55:12 UTC
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.
Comment 13 Alvaro Soliverez 2010-05-28 15:07:00 UTC
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?
Comment 14 warren_schaub 2010-05-28 15:47:35 UTC
Precisely, that is what I thought would happen.  Your analysis is spot on.
Comment 15 Alvaro Soliverez 2010-05-28 16:18:04 UTC
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.
Comment 16 Ian Neal 2010-05-29 00:01:37 UTC
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.
Comment 17 warren_schaub 2010-05-29 00:26:22 UTC
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.
Comment 18 Alvaro Soliverez 2010-05-29 02:51:53 UTC
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.
Comment 19 Ian Neal 2010-05-30 01:52:33 UTC
Revising bug summary to reflect nature of enhancement
Comment 20 Michael Carpino 2018-03-01 15:15:54 UTC
Enhancement requested over 5 years ago and add to wishlist.