[moneytalks] Re: Two bugs located in the recurringtransactions part of program
- From: "Barrett, Don" <Don.Barrett@xxxxxx>
- To: <moneytalks@xxxxxxxxxxxxx>
- Date: Mon, 14 Aug 2006 15:14:36 -0400
I think Rob gets the problem. I knew what was meant in both scenarios.
I simply was suggesting that a template could allow the memo field to be
successfully carried forward instead of being left blank so as not to
repeat what would become erroneous information.
I also understood the problem with recurring items occurring on
weekends.
-----Original Message-----
From: moneytalks-bounce@xxxxxxxxxxxxx
[mailto:moneytalks-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Zielinski
Sent: Monday, August 14, 2006 3:11 PM
To: moneytalks@xxxxxxxxxxxxx
Subject: [moneytalks] Re: Two bugs located in the recurringtransactions
part of program
Hi Don and Rob,
Don, I think Rob means that the manual should not indicate that the memo
is carried along in recurring transactions, that that is a mistake in
the manual itself. Right now, the program simply doesn't copy the memo
field from the transaction that one uses as the basis of a recurring
transaction.
I can understand that, and a simple change in the manual will solve the
probelm, unless, of course, the MT staff feels it's a good thing to
carry along the memo field like category and sub category are carried
now.
Now regarding weekend action. I am not talking about the notion that by
pushing a transaction to a previous Friday or following Monday that
somehow MT is acting incorrectly. I understand that feature.
The problem is when you use recurring transactions with weekend action
set to previous weekday or following weekday, and set frequency to 1 to
6 days, the number of transactions over time, and the financial amounts
represented will not be the same compared to setting weekend action to
"always post".
When set to previous weekday, or following weekday, over time, the
financial representation will be incorrect.
You can test this probelm in the following way:
If you create a recurring transaction using posting every x numbers of
days, from 1 to 6, and choose "always post", then expand the
transactions into the future, you will see different results from using
weekend action set to previous weekday or following weekday.
For example, make a transaction for August 14, set it to every three
days, set weekend action to "always post", and examine the results. You
will get postings on August, 17, 20, 23, 26, 29, September 1, etc.
Always multiples of three days from August 14.
Now change the weekedn action to either previous or following weekday.
Whenever the actual posting date is on a Saturday or Sunday, money talks
moves it either forward to Monday, or backward to Friday, depending on
the weekedn action setting. This is normal and not unexpected or
incorrect.
But here is the glitch. Money Talks takes that Friday or Monday posting
date, and computes three days forward from that date to determine when
to post the next occurrance. So in the example above, starting on
August 14 with weekedn action set to previous weekday. You get the
following dates:
Thursday, August 17, next,
Friday, August 18, which is correct, next, Monday, August 21, one day
later than it should be, next, Thursday, August 24, one day later than
it should be, next, Friday, August 25, the same date, only because MT
computed from Sunday, August 27. The correct date is Saturday August
26.
If you expand this let's say, to one year, you will get inaccurate
postings and inaccurate financial values, credits and debits. This
could cause quite a discrepency over the true projected values over
time, giving an inaccurate representation of your future funds.
I am advocating that this issue with weekend action be considered in the
next beta and changed to have the program show the same financial status
over time just like it does when using "always post". Short of that,
weekend action, when used with recurring transactions of less than a
week, are effectively of little value and a in fact, misleading.
I'm sure the MT staff are going to consider this, and if they disagree,
will have an explanation which will fall within the pervue and purpose
of MT, but I advocate making a change so as to allow accurate
representation of financial status over an extended time range,
regardless of whether weekend action is previous, later, or always post.
Hope I wasn't too confusing. <grin> I actually don't use the recurring
transaction feature on my MT program, partly because of this feature.
Steve
----- Original Message -----
From: "Barrett, Don" <Don.Barrett@xxxxxx>
To: <moneytalks@xxxxxxxxxxxxx>
Sent: Monday, August 14, 2006 12:44 PM
Subject: [moneytalks] Re: Two bugs located in the recurringtransactions
part of program
How about simply putting a [wo] in the memo field for the words "weekend
offset" for those postings where the post date is set back and thus
different from the computed date.
Don Barrett
Section 508 Coordinator
U.S. Department of Education
(202)-205-8245
don.barrett@xxxxxx
-----Original Message-----
From: moneytalks-bounce@xxxxxxxxxxxxx
[mailto:moneytalks-bounce@xxxxxxxxxxxxx] On Behalf Of ROB MEREDITH
Sent: Monday, August 14, 2006 1:30 PM
To: moneytalks@xxxxxxxxxxxxx
Subject: [moneytalks] Re: Two bugs located in the recurringtransactions
part of program
Steve:
Your bug number 1 is actually a problem with the manual, not the
program. We'll fix the manual.
As for your bug number 2, we need to einvestigate a possible solution.
A solution, while perhaps correct, goes against the current design
philosophy, so it won't be an easy fix.
Rob Meredith
>>> steveziel@xxxxxxxxxxxxx 08/12/06 03:07PM >>>
Hello MT staff and others,
I hope I'm not too late to get this fixed in the next release of MT.
I believe I've located two bugs in the recurring transactions part of
the program. I've used the project recurring transactions to test this.
I didn't let the program automatically post as the computer's clock
normally advances. I did use the "Post Next Occurrance" and "Project
Recurring" options in the Transaction menu to test this.
Bug number 1, dealing with how recurring transactions work with the memo
field:
The manual states at one place:
Status of Recurring Transactions
When Money Talks adds a recurring transaction to your register, it uses
the information from the last transaction in the Payee/Payer, Amount,
Item, Memo, and Category fields.
Usually, this is what you want, but there may be some recurring
transactions with amounts that differ from time to time. . . .
Problem:
The contents of the memo field of the original transaction, is, in fact,
not carried over. Recurring transaction memo fields are blank.
To test this:
Pick a transaction which has a memofield filled in, and make it
recurring. Project that item into the future. The memo field will be
left blank.
Bug number 2, dealing with inaccurate posting dates for recurring
transactions with frequencies of less than seven days, (a week):
To test this, I created a transaction on Saturday, August 12, then made
it recurring as follows.
Step 1. I chose Every X Days option under the Frequency combo box under
the Recurring sub-menu Step 2: I tabbed to the Number of Days edit box
and entered the digit 3.
Step 3: Tabbing to Weekend Action radio button I chose Previous Weekday.
Step 4: Under Advanced Days to Post, I left it at zero.
Step 5: I hit enter to accept the OK button.
Problem:
The program inaccurately posts the recurring transactions, putting them
on incorrect days and over time creating erronious results. I think it
is tied into the use of Weekend Action, but not in the way you might at
first think. I don't think this problem occurs if you set Weekend
Action to "Always Post".
Here's a description of what the results are and what I think they
should be.
Original transaction date, Saturday, August 12.
First occurrance: Tuesday, August 15, (3 days later, correct.) Second
occurrance: Friday, August 18. Correct.
Third occurrance: Monday, August 21. Correct.
Fourth occurrance: Thursday, August 24. Correct.
Fifth occurrance: Friday, August 25. Correct. The actual posting date
should have been Sunday August 27, but because Weekend Action is set to
Previous Weekend, it got posted on Friday, the 25th.
Here's where the problems begin:
The nnext occurrance should be Wednesday, August 30, because the 30th is
three days after the 27th.
However, the program places the recurring transaction on Monday, August
28, three days after its Friday, August 25 posting. It is using its
actual posting date based on the Weekend Action setting, rather than
what it should be based on, truely three day multiple projections from
August 12.
The next actual projection should be Saturday, September 2, and should
be placed in the program on Friday, September 1.
However the program places the transaction on Thursday, August 31, three
days after its last entry.
The next actual recurring transaction should be Tuesday, September 5,
three days after September 2.
However the program thinks it should be on Sunday September 3, three
days after August 31. Because September 3 is a Sunday, it enters it on
Friday, September 1.
The next actual occurrance should be Friday, September 8, three days
after the 5th.
However the program places it on Monday, September 4, three days after
Friday, September 1.
You can see how over time, the recurring transactions will not reflect
the real number of transactions that should be there, and hence the
actual amounts of the projections will be inaccurate. To be accurate,
At times the actual transactions, because of the Weekend posting
settings, should occur twice on a given Friday, (or Monday if you set
weekend action to the follwoing week day). As it is, the program simply
is placing a transaction three days after its last recurring posting,
regardless of the fact that this posting isn't a true multiple of three.
Over time, the discrepancy willl be larger and larger, and the money
values more and more inaccurate. This inaccuracy may become more
profound if you use different values for frequency from 1 to 6 days.
I believe MT should actually post in correct multiples of "number of
days" from the starting date of the recurring transaction entry. In my
example above, it should post in correct multiples of three.
If you concur, I hope I'm not to late to get this probelm resolved.
Steve
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date:
8/14/2006
Other related posts:
