Something I am noticing more and more often: I search for a particular name, and search results include items that have no relation to that name.
Shirley G has nothing to do with Floyd and Clara B. Nothing in Shirley’s T1 file has the last name “B”. When I click on the filename next to Shirley’s name, the T1 file for Floyd and Clara B opens, and there is no reference to Shirley in the B T1 file. Why does the Client Manager show a search result with an incorrect client name?
Stopping and restarting the TaxCycle server changes nothing. Shirley still comes up in the search results for “B”
After re-indexing the database, the Client Manager no longer finds any search results for Floyd or Clara - searching for “B” only shows Shirley G.
After working on the B T1 and saving it, the Client Manager finds SOME of the B entries, but also now attributes Shirley G’s T1 files to Clara B:
These are not the only clients who seem to be mixed up in the database, and it’s not always the same ones. If I run this search again tomorrow, it may find only “B” files, as it should. I more interested in understanding why the Client Manager does this, and if there is anything I can do to help it, or prevent the problem.
Happens to us too. Sometimes we can see the connection, like a last name of a client is the same name as a motor vehicle in another’s file, but there’s tons that have no common thread we can find. Very annoying and wasn’t like this in years prior.
Weirdly, if I type in the first three letters of my last name I get myself, my two kids…and a completely unrelated return. (I’d think that if it were keying on my name being somewhere, ALL returns would show up!!?)
Searching fro “bra” brings up one correct match and 4 incorrect ones with no apparent connection, either via substring or otherwise (similar to the “B” above).
Also: CM is taking FOREVER to load files on a “quick search” selection.
The search tries to evaluate what has been entered - is the text a SIN, email address or phone number etc. If it can’t determine what has been entered, it falls into a free-text search mode. This mode looks at a broad catalogue of taxpayer information such as personal details, addresses, slip issuers etc.
We could add an option to restrict free-text searches to only the taxpayer’s name, number and client ID only. This would tighten up the results.
I can’t see how that would help. If you type in a client name, why would it match that with a SIN or a phone number? Does it convert the text to the binary version of the ASCII characters and then match that with the binary version of numbers in other fields? I would expect that the only place it would find a MATCH is in fields that actually contain that text string, and it is not doing that. So, if you restrict the text search to only the fields you suggest, I expect the results will be no different than what it is doing now (or maybe it will simply not find ANY search results).
When I type in something that exists in my database (i.e. the name “B”), a free text search should easily find that. Why does it find files that don’t include that text string AT ALL??? Or even, sometimes, EXCLUDE files that DO contain that text string? And why does it mix up the client names and filenames in the list? It’s like when you perform a “sort” in Excel but you forget to include one column in the selected range. The resulting list is all mixed up.
Does this indicate corruption in the database? If so, why does re-indexing not fix the problem? Do I need to manually clear out old database files or something? Do I need to uninstall/reinstall TaxCycle? Do I need to uninstall other software that might be conflicting with the TaxCycle server? What other software is known to have issues co-existing with TaxCycle?
The service first tries to narrow the search on what is entered. If you enter a SIN, it only searches data that contains a SIN. It is unlikely that someone’s name contains a SIN (though there is an exception for Business names and numbers where this is common). This is the general rule for phone/invoice/ID numbers, email addresses and postal codes.
When the search text cannot be narrowed down to a SIN/BN, phone/invoice/ID number, email address or postal code, the search is broad. Client name, number, ID, contact, address, invoice number, slip descriptions, slip issuers, preparer ID, and special instructions are included in the search. This can produce many results. For example, we have seen someone’s surname in the street address of another individual present in the search results.
My proposal was to restrict the search to just client names, numbers and IDs when the search text cannot be narrowed down. Addresses, instructions, slip descriptions etc. are excluded from the search. This produces fewer more focused results.
If you enter someone’s name, and there are no matches that is an issue.
Is the individual’s return in a monitored folder?
To index a return, a minimum set of data is required. For an individual, their sin, date of birth, and first & last names should be present in the return. For businesses, their number and name.
Password-protected returns are not indexed and won’t be shown.
Does the service have sufficient permissions to read the contents each monitored folder?
In the server log folder, there is an Index Report file. These reports contain a summary of an index including returns that could not be indexed. [C:\ProgramData\Trilogy\Services\Log]
If you move returns around using File Explorer often? The service may miss that the return was moved because Windows does not guarantee interested applications we be notified.
Concerning data integrity. I would suggest the following (highlighted) server settings:
If you opt to run a manual index, it is recommended that you also ‘reset the database’. This clears all data from the database before indexing returns.
The server should be appropriately resourced given the number of tax returns being prepared. Firewalls may prevent communication between the service and TaxCycle on networked workstations, but this would not affect indexing tax returns. There are no other known third-party applications that interfere with the Client Manager service.
Thanks @Andrew that was quite thorough, but it doesn’t help. I have personally examined every field and data entry in Shirley G’s T1 file - the text “B” DOES NOT EXIST ANYWHERE IN THAT FILE. I have reset and re-indexed the database multiple times in the last week. So, I can’t understand why the Client Manager still finds “Shirley G” when I search for “B”. Are there fields (or other data attached to a file) which we users can’t see but the Client Manager does?
@Nezzer We have removed the images and redacted the names to ensure that no sensitive client data accidentally appears on a public web site. If @Andrew needs the images, please send them into support. Thanks!
Thanks @Elizabeth. I did redact the SINs prior to posting, so I think it would be ok, but I guess it’s better to have as little as possible that could be traced back to an actual person.
Are you able to share this particular return? Anonymize the SIN etc. We can then step through the indexing and search process to see why a “B” is matching this return. Email info@taxcycle.com and they will provide a link to share the file securely through titan file.
