Are you using a custom theme? The #### representation generally means the contents of the field won’t fit. Have you added things to a theme that would have taken up space?
Also, can you post some screen shots of more offending transactions? Try to find some that show “Null” or have a mixture, as you mentioned. And then post the corresponding view of the finished transaction. You can obscure proprietary information if necessary, but show the portion of the finished transaction with the Tax column and Totals.
I’m not sure what you mean about themes - this is in the Edit view, as the tax code isn’t visible on the final document. However, I don’t think I have themes enabled, either.
In every case, the tax code should just be empty (“No tax”) but is sometimes #####. Maybe empty field was treated differently in an older version of the software? I often clone these sorts of transactions, so that sort of thing could easily persist.
The “null” just flashes for a split second sometimes - so far I haven’t been able to grab a screenshot.
You can read about themes here: Manager Guides. But I suspect if you were using one, you would already know about that.
That’s possible. If you downloaded the previous version on 1/21/2017, it would have been several hundred updates old, because Manager advances so rapidly. But I don’t think any major changes that affected database structure were involved with tax codes during the last year. But I’m not the developer, so I can’t be sure. I only know that basic tax code functionality hasn’t changed during that time. Implementation could have. But the mixed situation is what puzzles me. I have test companies with transactions all the way back to 2013, and I can’t find any examples that match what you are showing.
Let me ask you to do two bits of experimentation:
Go to Settings > Tax Codes and post a screen shot of the list of tax codes that you have in effect.
On the Edit screen of one of the transactions showing this problem, click on the dropdown arrow. After clicking, don’t click anywhere else in the Manager window. With the dropdown tax code list showing, capture a screen shot of it. If there is truly no tax code selected, the cursor bar should be on the first tax code in the list. On the other hand, if something unknown has been selected and is causing the #### behavior, the cursor bar should be on that.
When clicking the dropdown, the cursor bar is on the first tax code (and ##### is not in the list). Selecting any other tax code, or clicking the X to remove the tax code, resolves the problem. But it must be done one at a time.
Poking a bit in the HTML source, I got the key of the ##### tax code:
I looked this up in a SQLite database viewer and see that this key doesn’t exist anywhere, not in any older files in the Manager folder either. So for some reason I guess there is this dangling tax code. (The other legitimate tax codes do exist in the database, and the ones that say “No tax” don’t have that entry in the HTML at all.)
Simple search of the .manager file shows there are 506 references to this non-existent tax code. On a backup file I am seeing if I can at least get a list of affected transactions to fix.
After fixing each transaction, the Boguscode can be deleted.
I saved the backup, in case it can help with debugging - although it must be some legacy thing about this file. Who knows when the problem actually surfaced…
Well, this turned out as a pleasant surprise. From your earlier posts in the thread, you sounded like something of a computer novice because of your uncertainties. Obviously, you aren’t, and you went well beyond anything I could have helped you with. I suspect you are right, that the problem is the legacy of one or more updates in the past. Perhaps I didn’t happen to update at exactly the same stages you did and thereby avoided the problem. Maybe @lubos will have some idea what could have caused this.
At any rate, your solution was elegant. I’m glad things worked out. I’m also glad that there apparently weren’t any effects on actual transactions.
