Both use the nextPayment method. If an alternative nextAdjustedPayment is provided, then it's an easy fix.

Created attachment 40023 [details]
Payment Dates patch v0.1

This patch:
* Creates a new method in mymoneyscheduled.cpp called adjustedNextPayment that returns a date adjusted, where appropriate, for non-processing days;
* addScheduledTransactions in mymoneyforecast.cpp makes use of new method to calculate the correct totals of each day of each schedule;
* Tidies up adjustedNextDueDate;
* paymentDates in mymoneyscheduled.cpp makes use of adjustedDate to create a properly adjusted for non-processing days list of dates for a scheduled transaction;
* updates mymoneyscheduletest.cpp so testPaymentDates does not fail with adjusted dates.

It looks good to me. 

There is one more place to change for the reports, in pivottable.cpp, line 193 and on.

SVN commit 1076906 by asoliverez:

Have forecast and reports use the adjusted date.
The calendar view is still to go.
BUG:223349

 M  +4 -3      mymoney/mymoneyforecast.cpp  
 M  +34 -36    mymoney/mymoneyscheduled.cpp  
 M  +14 -0     mymoney/mymoneyscheduled.h  
 M  +40 -23    mymoney/mymoneyscheduletest.cpp  
 M  +1 -1      reports/pivottable.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1076906

I commited the patch by Ian Neal. The calendar view will be a bit more tricky.

As far as I am aware the calendar view uses the widget kmymoneyscheduledcalendar which in turn uses the kMyMoneyScheduledDateTbl widget. That uses scheduleListEx which is implemented by the various storage methods all of which, as far as I can see, use paymentDates to generate the list of scheduled transactions that are due to occur on a particular day.
As this patch fixed paymentDates, is there anything else that is needed for calendar view?

You are right. It should be fixed then. Can you confirm?

(In reply to comment #7)
> You are right. It should be fixed then. Can you confirm?

Yes, all seems fixed for all the tests I can do.