Two zeros get added to an entered number (the number gets multiplied by 100) each time I press the Enter key!

[rjs]

@fa123  If you start a new tax return from scratch, without transferring from last year (just as a test), does the same problem occur in the new return, or is it only in your return with information that has been carried forward for years?

[fa123]

@rjsVery good point.  I actually had not tried this before (I don't know why, it is such an obvious thing to try).  I was so hoping that this would work and then we could localize the problem to the transfer function of Turbotax. 

I just tried it now and started a new 2020 return from scratch, without transferring anything.  Unfortunately, yes, the exact same thing happens here too.

So here I start with a fresh return, no transfer, enter enough data to get myself to entering a 1099-INT form (just for a direct comparison to my previous posts).  Here is the initial screenshot where I enter the name of the bank:

Now I open a Supporting Document list for the Amount field and enter "Item A" for the description of the first item:

After pressing the Return key, I type in 10.58 for Amount:

And then hit the Return key and see:

I type "Item B" and get:

Now I type 20.00 for the Amount:

And click on "close" and see 305,800.00 as the total for 10.58 + 20.00!!!

Next, I right-click to open the same Supporting Detail list, but before I select the menu item to actually open it, I see the interest income value get multiplied by 100:

And here is when the list is actually opened.  Observe the total in the list, and compare it with the total in the Interest income field (once again increased by 100 times compared to its value in the previous screenshot:

And I just click on "close" to close the list without having changed any of the items in the list:

I think this answers your question.

[SteamTrain]

Hmmmm....I was wondering.....does it only happen when the Supporting Details sheet is used ?

i.e.  if you delete thee SD sheet, and only put in the initial interest  $10.58 in the main field, does that always remain the same proper value?   or does that end up jumping by 100's too?

[rjs]

I know you said you have a US keyboard and "US English settings," but this sure seems like a localization problem of some sort. TurboTax is strictly a U.S. tax program. It's designed to run on U.S. computers, and does not work with other region, language, or localization settings. I gather that you are not in the United States, so maybe something you are doing to adapt to your location is contributing to the problem you are having.

Do you have multiple keyboards on your computer? If so, when you are using TurboTax, click on the language icon on the taskbar and make sure that English (United States), US Keyboard is selected.

Please double-check all of the following settings, just to be sure. Something obscure might have gotten changed accidentally.

Go to Settings > Time & Language > Region.

Country or region should be United States.

Regional format should be English (United States).

On the left side, click Language.

There are several icons at the top of the Language panel. They should all say "English (United States)."

Windows display language should be English (United States).

Under Preferred languages, is more than one language listed? If so, English (United States) should be first in the list. If it's not, click on it and move it up to the top.

Click on the Keyboard icon at the top. On the Keyboard panel, "Override for default input method" should say "Use language list" or English (United States) - US. This is assuming that English (United States) is at the top of the Preferred languages list.

Is the box checked that says "Let me use a different input method for each app window"? I don't know how that works. If that box is checked, you have to make sure that you are using English (United States), US Keyboard in the TurboTax window.

Go back to Region. On the right side, scroll down a bit to Related settings and click "Additional date, time & regional settings." This will open a Control Panel window. In the Control Panel window, click on Region. At the bottom of the Region window, click "Additional settings."

On the Numbers tab, check all of the following. The period and comma can be hard to see, especially on a laptop screen. Look very carefully.
Decimal symbol: . (period)
No. of digits after decimal: 2
Digit grouping symbol: , (comma)
Digit grouping: 123,456,789

On the Currency tab, check the following.
Currency symbol: $
Decimal symbol: . (period)
No. of digits after decimal: 2
Digit grouping symbol: , (comma)
Digit grouping: 123,456,789

[SteamTrain]

Yeah...I was thinking that too, and brought it up earlier...but didn't pursue since some of it didn't seem to fit with some of his multiple <Enter> blowups.    but thinking about it again...that could still be the issue.

A number of European countries use decimals as thousands separators instead of commas, and commas where we use  decimals, and that  could blow up those numbers in a totally confusing way.

Thus a USA 10,000.34   is a European 10.000,34     

So how does the software treat those numbers if the region setting is set to one of those reverse numerical separator regions ?

[rjs]

Yes, now I'm sure that's the problem. On my U.S. English computer, if I enter 10,58 it gets changed to 1,058.00. So if you enter 10.58 on a computer that has the period and comma reversed, it's going to become 1.058,00, which is exactly the behavior that fa123 is experiencing. But it seems like fa123's problem is not quite as simple as having a European numeric format setting. In his screen shots, the numbers are displayed with the U.S. usage. But when he types a period, it's being interpreted as a grouping character, not as a decimal point. Maybe he'll find something out of whack in one of the "additional settings" or one of the other settings that I asked him to check.

[SteamTrain]

Yeah, I was noticing that the display seems to be US notation too...but I think the SD worksheet is some kind of a subroutine.....and we have no idea if it was written in the same programming software package as the main program, or not.   When the numbers transfer to the main program when closing the SD Sheet, is it passing thru some field that uses the regional numerics setting, where the main program does not?  All kinds of chaos may occur.

I was tempted to test a different European regional setting...but I'm too afraid it will mess something up on my real tax return, even if I don't access it during the change-over. 

now....If I had another unimportant, almost never-used computer to install TTX on....?

[fa123]

Thank you very much everyone. The problem indeed has to do with regional settings and I have now resolved it on my end by fiddling with the regional settings on my PC. However, it seems to me that we share/shared a common misconception. So, allow me to clarify.

Indeed, I live in Europe, but my PC keyboard/language settings all are US English. Like @rjs I also had the impression that "TurboTax is strictly a U.S. tax program." in the sense that it would parse and interpret and display numbers, currency, dates, etc., according to the US standard format. (Why should it not? Who other than a US taxpayer would ever have any reason to use this software?) If this were actually the case, though, Turbotax would parse, interpret, and display numbers all according to the US standard format, come hell or high water. This means that if a Martian were to run TurboTax on her PC with Martian regional setting, according to which "/" is the decimal separator and ":" is the digit grouping separator, then Turbotax would still parse "10.58" exactly the same way as it would on a US PC, and would also display that value as "10.58" exactly as it would on a US PC. However, this is NOT what Turbotax does! Please bear with me ...

There are only two justifiable, consistent alternatives for the I/O behavior of a software: (1) the software picks a particular I/O formatting standard (say US) and hard-wires it in its code to abide by it throughout, disregarding the regional settings of the OS; or (2) the software chooses not to have an internally hard-wired I/O formatting standard and instead abides by the formatting standard selected by the regional settings of the OS.

As far as I know, up to a few years ago, Turbotax seemed to behave according to the first alternative. Its recent versions, including the 2020 version, do not behave according to EITHER alternative. We have now "discovered" that Turbotax parses and interprets its input according to the formatting standard selected in the regional settings of the OS, but displays numbers according to the US standards. I know there is a good/excellent reason for Turbotax to use the US standard in its output (see below). Nevertheless regardless of that or any other reason, this I/O behavior (using two potentially different standards for input and output) is inconsistent.

Older versions of Turbotax, as I mentioned, serve as examples of software that consistently behave according to the first alternative, mentioned above (all consistent and well). Other software, e.g., for form filling in Adobe Acrobat, behave consistently according to the second alternative, above. What this means is that if Windows ever offered a Martian regional settings, then Adobe Acrobat running on a PC with Martian regional settings would interpret a "1:357/26" typed entry as the numeric value we would represent as "1,357.26" in the US format; would actually display this numeric value as "1:357/26" which is so intuitively familiar to a Martian; and would bark at anyone who ever typed such gibberish as "1,357.26" which cannot be interpreted as a valid Martian-formatted number.

More to the point, if Turbotax chooses to parse its input numbers according to the regional settings of the OS, then to be consistent (alternative 2, above) it must also display its output numbers according to the same regional settings of the OS. This means that on a PC with regional settings that use "," as decimal separator and "." as digit grouping separator, Turbotax must:

(a) bark at you if you type "10.58" because the digit grouping separator must separate groups of 3 digits (Adobe correctly barks at you);

(b) display the numeric value "ten thousand five hundred eighty two" of the typed input "10.582,00" exactly as "10.582,00" (i.e., not "10,582.00"); and

(c) if for any reason it fails to bark and accepts "10.58" as legitimate input representing the numeric value "ten thousand five hundred eighty" then it must display it as "10.580,00" (i.e., not "10,580.00").

But here's the rub: The sole purpose of Turbotax is to produce forms according to the standards set by the IRS and other tax authorities in the US. Obviously, the IRS would not be pleased to see "10.582,64" (not to speak of "10:582/64") in lieu of "10,582.64" anywhere in its forms. Therefore, the output format of Turbotax must abide by the US standard, even if that output is produced by Turbotax running on a PC with Martian regional settings. What this means, therefore, is that in order to be consistent, Turbotax must NEVER subordinate how it interprets its numeric input to the regional settings of the OS, and instead ALWAYS parse and interpret its input according to the US standard format. Turbotax used to behave that way up until a few years ago. As we see, it no longer does.

I maintain that this (potentially inconsistent I/O behavior) is a (design) bug in Turbotax. I say so because there is no justifiable reason for Turbotax to ever treat its input according to anything other than the US format (regardless of the regional settings of the OS), given that its output format must always be according to the US format. You never encounter this inconsistency bug as long as your OS regional settings happens to be consistent with the US format.

For the sake of completeness, if you do not live in the US (and there are quite a few expats out there) it is not a good idea to just change your PC's regional settings to US wholesale, because that may affect your date, time zone, etc., and mess things up on your PC.  Windows allows you to fine-tune your settings. 

Here is what you need to do to make your regional settings compatible with the US number format (this may still cause problems with your other applications, such as form filling in Adobe Acrobat), so you may want to reset these settings back to your local settings once you're done running Turbotax (at least until Turbotax fixes this bug in a future version, if ever).

Go to the Time & Language part of your PC Settings:

Next click on "Date, time & regional formatting" link on the right edge of the above window to see something like:

Now click on the "Additional date, time & regional settings" link on the right edge of the above window.  A new window opens:

Under Region in the above window, click on "Change date, time, or number formats" to open a new window as the following:

Now in the above window, click on the "Additional settings ..." button to open yet another window like the following:

In the above window, make sure you select "." as the "Decimal symbol:" and "," as the "Digit grouping symbol:"  Then click on the "Apply" button, and then click on the "OK" button to close the window.

[fa123]

BTW @SteamTrain  and @rjs No, it is NOT only in Supporting Details lists where this formatting issue shows up.  There are other places where direct entries in forms also exhibit this same problem.  However, this is not consistent either, i.e., this problem does NOT show up universally for all numeric input everywhere in Turbotax.  This indicates that internally, Turbotax software has more than one piece of code that parses and interprets numeric input data.  Some such pieces of code interpret input according to the US format (disregarding the OS regional settings), and some of them interpret their input according to the OS regional settings.  Naturally, the output is always in the US format, for obvious reasons.

[SteamTrain]

@fa123 

I don't disagree with you......but I doubt TTX is going to do anything about it.  At least not right now since they have a lot of other huge issues to deal with...maybe @rjs can get the Moderators to put forced number  formatting on their Software changes wish list for later after things quiet down.

Yeah....there was a year when a whole bunch of changes were implemented, that also caused other problems.  Essentially, any section where you entered it, and there was a pause with a momentary "Please Wait" and a rotating blue circle.   One example can be seen when you go into the Federal Quarterly Estimated taxes section...but Not when you go into the State Quarterly Estimated taxes section.  The display layouts of the two sections for the 4 quarterly payments can clearly be seen as being different too.

[fa123]

@SteamTrainI understand.  I'm not holding my breath for a fix for this bug, either.  I've learned to work around it and I've already filed my 2020 return with the IRS (and they have accepted it) as well.  Through these discussions (thanks to everyone who participated), I now have a better work-around for 2021, if the bug is still there next year.  I'm now waiting for the March 19 Turbotax update that promises to fix another bug I encountered and reported on a different thread (https://ttlc.intuit.com/community/state-taxes/discussion/re-turbotax-wants-an-outrageous-250-state-e...) so that I can finally file my 2020 state tax return too, and be done and archive this year's whole tax stuff.

[TasnimH2]

Hi @fa123 

Thank you for your patience. My team and I replicated your issue using the token # that you had sent me earlier. The issue did not pop up in our program (TurboTax Deluxe Desktop version). We can also confirm that it is not a return file issue either. 

We would suggest that you call & speak to IT support. I am confident that the issue will be solved. Another option is to reset your taxes and start over from scratch. 

I hope this helps.

[TasnimH2]

@fa123 glad to hear that it was resolved 🙂 Thanks @SteamTrain @rjs 

[SteamTrain]

@TasnimH2 

Got it...good to see you were able read his last couple of posts to see where he determined that it was  a regional setting, or European numerical format setting that  resulted in his entry chaos. 

BUT...it would help any ex-pat, living un Europe, and filing from overseas using the desktop software, if the Tax software programmers could some how lock in US formatting for all $ amounts entered into any fields.  Put it on the Tax rewriting/updating wish list for next year.

Certainly, I don't know if that is actually possible....but seems like it could be done.

[TasnimH2]

Hi @SteamTrain this is good info. I will pass this along to the developers. 

Glad the user was able to file.