Today’s digest has us finding the missing client data…
It seems that when a T183 is sent out for signature, the system is now setting a second 2020 engagement. So, I have found the missing data… it is the 2020(1) engagement and the report that was sent out for signature is in the 2020(2) engagement!
Very specific to where the client is sent an activation email, they setup their account, upload their info. Thus creating the 2020(1) instance.
TaxCycle upon ‘printing to’ tax folder is creating a second instance 2020(2).
Has anybody else seen this sort of thing happen.
Mark.
On a positive note, I have received a lot of compliments on the 2FA.
We note that if you print a print job to TaxFolder, TaxCycle is not sending the right engagement label, so if you’ve created a label that doesn’t match the default, a new engagement folder is created. That’s fixed for the next release.
Starting with the next release, TaxCycle will be more reliable with that. Also, if you’ve printed to an engagement folder for a client, the next thing you send to that client from the TaxCycle file will default to the same engagement folder.
Thanks for the information, your patience, and for helping us work through the initial issues.
I have sent a few items for signature via TaxFolder so far. The Engagement Letters came back fine. The T183s are not coming back the same; they are coming back complete but not signed. I have sent a note to support but came here to read up on more guidance. Help?!
I know this goes without saying, but when the mobile numbers are incorrect…specifically in TaxCycle, we loose the ability to authenticate for the signature.
At present, there is no way to work around this sort of error. Can there be a routine developed to show identify the mismatching mobile numbers?