Vic Dura wrote:

- quote -

And pardon me for sounding like a broken record, but that is
because TaxACT does NOT, NOT, NOT support the Alabama
part-year return.

Here is a link to a "fill=in" PDF form at the Alabama DOR
site. Perhaps it would be more appropriate for your needs:

http://www.ador.state.al.us/incometa...orms/04f40.pdf

MTW

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

RE: Re: Tax software design
Harlan Lunsford <hlunsford[at]bellsouth.net> wrote:

- quote -

No, unfortunately TA does not have that for Alabama. I wish it did. In
fact, for AL you can't even check (within the program) the part-year
resident box on Form 40.

--
To reply to me directly, remove the XXX characters from my email address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

"D.F." <sendnomail[at]please.com> wrote:
- quote -

Sorry for not being more explicit, the "Others" I was
referring to was in another forum.

--
To reply to me directly, remove the XXX characters from my
email address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:
- quote -

Not familiar with Tax Act, however, my program, TaxWise, out
of Rome, GA, has a resident/non resident allocation page
where you do the math and it will therefore carry over to
the Alabama sch b, or e. Maybe your's has same?

ChEAr$,
Harlan Lunsford, EA n LA
Sun 30 Jan 2005

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

I had a client who moved to CA from Georgia in 1998. I did 2
Sch. Cs for her returns, one Georgia and one California.
That made it clear to everyone. Now Lacerte allows input
coded to specific states. I would still use 2 Sch. Cs to be
clear.

Linda Dorfmont E.A., CFP ,CSA

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Barry Margolin <barmar[at]alum.mit.edu> wrote:

- quote -

I am not a tax pro, just another user who has been part of
this discussion in the software group mentioned.

I agree with you. I would expect that any override I make
will flow "forward" correctly, and that, of course, means
the total an the bottom of the form should be correct. What
I cannot assume is that the override will flow "backward" in
any manner.

--
Vic Roberts
Replace xxx with vdr in e-mail address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:

- quote -

Strangely I could not find a posting that could be
paraphrased into the above interpretation. I did find some
that said in effect, if you override, you are on your own.
The implication to me was that the development efforts
should be applied to deficiencies in the standard things
rather than overrides.

Of *course* the program should behave as you say. I don't
think anybody is saying otherwise. And I think that should
probably be a high priority issue with them, right after
being able to read TXF files into schedule D. ;-)

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Harlan Lunsford <hlunsford[at]bellsouth.net> wrote:

- quote -

TaxAct Alabama, but I've read that the behavior is the same
for some other states, although I have no personal
experience with other states. That's why I believe that the
behavior is by (poor?) design.

--
To reply to me directly, remove the XXX characters from my
email address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Barry Margolin <barmar[at]alum.mit.edu> wrote:

- quote -

Well put. Yes, that is how I feel about it.

--
To reply to me directly, remove the XXX characters from my
email address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Good tax software might provide 2 or 3 ways to compute
taxes. One might be by logically categories: income,
deductions, etc. One flow for individuals. Another for
self-businesses, etc. Another flow that essentially tracks
the forms box by box. And all these would be cross-linked,
so you switch among them and fill in any order.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura <vpdura[at]XXXhiwaay.net> wrote:

- quote -

I'm not a tax pro, just a long-time, layman user of TurboTax
(and Macintax before it). This "feature" seems ridiculous
-- isn't one of the main points of using tax software that
it should perform all the calculations for you? If the tax
form says that a field should be the total of some other
fields, the software should do the addition for you. If you
override one field, you expect the software to use that
value in all calculations involving the field.

--
Barry Margolin, barmar[at]alum.mit.edu
Arlington, MA

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:

- quote -

First, permit me to point out that the software product in
question explicitly states that they do not support the part
year return that you were trying to prepare. Further, they
also explicitly warn that overrides may cause "unintended
and unforeseen consequences." In other words, I believe you
were trying to "trick" the program into preparing an
unsupported form by using a technique (overrides) that the
program warns against.

That said, I believe the "design flaw" with respect to the
Schedule B in question is that it allows overrides in the
first place. It shouldn't, and your example demonstrates why
(because all kinds of other things might go wrong). If you
don't like the results on Schedule B, you should correct
them by changing the input on the related 1099-INT/DIV input
screens, NOT by doing direct overrides on the Schedule B.
(The same applies to Schedule D and any other form that is
driven by 1099 input.)

It is clear to me that the architecture of the program in
question is designed around electronic filing. With that in
mind, it is paramount that the information entered on the
1099 input screens remain intact and NOT be modified by way
of overrides entered on other forms. I, personally, don't
care much for electronic filing, but I recognize that it is
the driving force behind tax software design today.

I also recognize that when I choose to use an override, I
must assume full responsibility for the outcome. I would
not, and do not, expect the program designers to foresee all
possible consequences of an override. (On the other hand, I
DO expect the program to properly handle the forms and
calculations that it OFFICIALLY SUPPORTS.) The override
feature is simply provided as a convenience. But, as your
example demonstrates, it can get you into a lot of trouble.
<grin
Lastly, I wouldn't consider the result you achieved to be a
program "feature." Rather, I would consider it to be exactly
as the program warns: an "unintended and unforeseen
consequence."

The purpose of my comments has been to stress the importance
of selecting a tax software product that is appropriate to
your needs (rather than to provide "how to" technical
support for a particular product) and therefore I believe my
comments to be reasonably "on topic" for this newsgroup.

MTW

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:

- quote -

Of which tax program are you speaking?

Most I should think are like mine, Taxwise, in which there
is a form for allocating income among states. Look for it.

On another note, though, "overriding" is a really good
feature, because all interest income for example may not
have been ratably earned between two states for the whole
year. If my client moved from Georgia to North Alabama in
July and only then did he buy a CD from Southtrust, then
all of that interest is allocable to Alabama, and none to
Georgia.

ChEAr$,
Harlan Lunsford, EA n LA
Wed 26 Jan 2005

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

"Vic Dura" <vpdura[at]XXXhiwaay.net> wrote:

- quote -

you are 100% correct - an incorrect total cannot rationally
be construed as a "feature". If there is some benefit, the
software should show the incorrect total (i.e. the 1040
total) with some big flag for the user to correct it and
double check as part of the process. But, if I were using
this stuff, I would just want the total to be right.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

"Vic Dura" <vpdura[at]XXXhiwaay.net> wrote:

- quote -

Wouldn't it make much more sense to on the initial input to
code which state the income comes from?? Especially for a
part year resident!

--
David M. Woods, EA, ChFC, CLU
Woods Financial Services
Norwood, MA 02062
www.woods-financial.com

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:

- quote -

If your state has such a requirement then the software
should provide a special state schedule to do that. Now this
program would likely cost much more than 20 bucks.

--
Frederick E. Jorden http://Tax-Accounting-Payroll.com
7825 Midlothian Tpk - 207 Richmond, VA 23235-5247
EMAIL knowtax[at]bigfoot.com
(804) 320-6210 FAX (804) 320-6211

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

Vic Dura wrote:

- quote -

I'd want it to work the way my current software works. I
designate each entry as belonging to a specific state (only
for multi-state returns, but that's the only time you'd have
this situation), and the software carries the appropriate
amount to each state return, and the total to the Federal
return. No overrides necessary. That preference
notwithstanding, software that produces a schedule that
doesn't foot is worse than no software at all, IMHO.

Phoebe

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->

In a tax software related group we have been discussing the
behavior of the tax program. There are some differences of
opinion and I wanted to get the opinion of this group as to
how a particular situation *should* be handled by the
program.

The situation is this:

In the state version of a tax software package there is a
Sch-B for income and dividends. As expected, the entries in
the state Sch-B are drawn from the Fed 1040 Sch-B. IMO this
is good and correct.

However, due to facts and circumstances, the individual
entries on the state/B as drawn from the 1040/B are not
correct for the situation (part time residence in state) so
they must be overridden. The necessary individual entries on
the state/B are overridden with no problem. So far so good.

Now at the bottom of the state/B is a "Total" line which is
the sum of the entries above it. Before overriding anything
this total correctly indicated the sum of the individual
entries (those drawn from the 1040/B) above it. However
after overriding individual entries on the state/B, the
Total does not change. It does not reflect the sum of the
entries above it, but rather it reflects the original values
prior to overriding. The Total itself must be overbidden to
reflect the correct value.

IMO this is a design flaw in the program, as several other
schedules exhibit the same behavior. I also believe it is a
design flaw because seeing that the Total is not correctly
update and needs to be overridden, one must now ask himself
if it is the overridden or original (incorrect) Total that
flows to wherever it is required in the particular return.

Others do not see it as a flaw or bug, but rather a
"feature".

Does anyone have any comments or opinions on this one? :-)
If you, as a tax pro, were specifying the design of the
software would you specify that a "Total" automatically
update when one of it's constituents is overridden? Or would
you require the user to manually override the Total also?

--
To reply to me directly, remove the XXX characters from my
email address.

<< -------------------------------------------------> << The Charter and the Guidelines for submitting > << messages to this newsgroup are at www.asktax.org > << ------------------------------------------------->