[moneytalks] Re: Another problem with Memo Replication
- From: "Barrett, Don" <Don.Barrett@xxxxxx>
- To: <moneytalks@xxxxxxxxxxxxx>
- Date: Mon, 14 Aug 2006 14:11:40 -0400
Down the road, it might be possible to have a template of check boxes
which might include for example: current month, current day, current
year, static words, etc. which would build the memo field according to
specs each time a recurring transaction was posted. Just a thought for
later on.
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 TERRIE TERLAU
Sent: Monday, August 14, 2006 2:05 PM
To: moneytalks@xxxxxxxxxxxxx
Subject: [moneytalks] Another problem with Memo Replication
The Memo field is also printed in the memo section of checks that you
print. Rob's example of the problem with January rent repeating on every
recurring transaction becomes even more problematic when it is printed
on the check for August's rent -- and the landlord gets a bit confused
too.
Terrie
Mary T. (Terrie) Terlau, Ph.D.
Adult Life Project Leader
Department of Educational and Technical Research American Printing House
for the Blind
1839 Frankfort Ave.
Louisville, KY 40206
Phone: (502) 899-2381
Toll-free: (800) 223-1839 ext. 381
Fax: (502) 899-2269
Email: tterlau@xxxxxxx
>>> rmeredith@xxxxxxx 08/14/06 01:57PM >>>
Gary:
Actually, the memo is never replicated in recurring transactions.
Before I get a flood of emails requesting this feature, let me explain
why it is the way it is.
1. Imagine you write something like "January rent" in the memo field.
Replicating that would do you no favors, since you would have to change
the memo of every posted recurrence. Better to just type whatever you
want, or just leave it blank.
2. The same is true when other circumstances besides the date change.
It just seems like if you wanted to replicate the memo, it would just
get in the way. And if you were able to replicate the memo, you would
always be able to anticipate what it says, so there really would be no
point in replicating it.
Rob Meredith
>>> gwunder@xxxxxxxxxxxxx 08/14/06 01:36PM >>>
Okay, re bug 1, does this mean the memo is taken from the first and not
the last recurring transaction? If so, is there an easy way to find that
first one so that we don't have to enter the memo each month?
Thanks sir.
Gary
----- Original Message -----
From: "ROB MEREDITH" <rmeredith@xxxxxxx>
To: <moneytalks@xxxxxxxxxxxxx>
Sent: Monday, August 14, 2006 12:30 PM
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
>
>
Other related posts:
