I carried forward a prior year tax return, which includes the employer name on T4. When I import data from AFR it creates a new T4 slip since the employer name doesn’t match exactly. Now my prior year info is in one T4 and the new data is in the other.
Is there someway to merge the two T4s into one?
I would suggest that you delete the extra T4 that was created on importing from AFR and redo the AFR request. When you get the dialogue window just before importing, select the existing T4 to which you want the data to flow.
Got it. Thanks.
I am having some difficulties with AFR as well. When a client has a large number of slips, it is difficult to match a CRA slip to an existing one if there are a number of slips from the same issuer (and in some cases the slip selection popup window covers the slip detail). Last year we made a concerted effort to put the slip account number (if one existed) in the account number / description field for clarity (on the preseason letter). Just wondering what the algorithm is that determines the matching of the CRA slips to existing ones (name only, name and account, ???)? Wondering if it would be of value to “import new” for all slips this year so next year would work more smoothly?
@gil –
We only use the slip issuer to match the slips. Unfortunately, AFR usually does not include the account number, so we can’t rely on it.
When we import the slip, whether as new or not, we overwrite the issuer name to match what CRA has, so importing all as new will not make a difference.
For the next version, we are making a few improvements to the matching of T5008 slips… we will match on both the slip issuer and the security name, so that it works a little better when you do AFR more than once for the same client.
There is more we could do when matching slips when the issuer name doesn’t match exactly… just out of curiosity… how similar is what CRA has to what you have? Just a letter or two different, or major differences. Just some idea of how close the data is (generally) will help us improve the slip matching.
Best,
~ Cameron
When importing the AFR slips, does the process also
overwrite the existing account number/description field? As well, it
appears not to import joint slips.
Regarding your question about the issuer name, in my
case the name I have on file and the name imported from CRA are not even close,
because there was no value in manually inputting a long name into TC (last
year). Given that the name is overwritten, next year should be better.
At this point, it is taking more time trying to match
the imported slips to the existing ones, than it is to simply key the amounts
into the corresponding existing slip (to take advantage of the “last year”). However, given that I now have access to the CRA slips, I feel it is incumbent on me to import, because I have
found that some clients are missing slips. Difficult to justify raising
fees for this. I would appreciate any tips that other preparers have.
Does AFR participation require that the information be
automatically imported, or could there an option to have the information be
suspended like TDD was last year, to be imported or “use TDD value” as needed?
No… but we will for T5008 slips starting with the next release…
What do you mean? The CRA schema does not give us any indication if the slip is joint.
I’m not sure what you mean by “suspended”. If you import AFR information into a slip that already has data entered, the imported data will be in it’s own column and a “use AFR value” quick fix will show if the imported values do not match what you entered previously.
~ Cameron
Joint slips - T3 - Beneficiary Code 2 (Box 18), T5 - Recipient Type Code 2 (Box 23), T5008 - Recipient Type Code 2 (Box 11). Upon further review, AFR is importing joint slips (in my case, T5008), but it is creating a new slip for each transaction that is listed on the T5008. So TC has two T5008 entries with 1 physical slip provided by the client.
Regarding “suspended”, that was the functionality I was looking for - the AFR amount in it’s own column, available to be copied to the actual data field.
@gil –
Okay, let me investigate that further. It may be just that CRA did not give us an test cases with joint slips.
If you have some clients that have joint slips, you can help by looking at the XML file that you get from AFR… get it by clicking the button circled in red below:
Take a look at the XML and check to see if the joint information is there…
Once I have some real world data we can create some review messages for joint slips the same way we do for SlipSync.
UPDATE: Allen has confirmed that the AFR schema does not include the beneficiary/recipient code fields for those slips. We’ll suggest that CRA add that for next year.
With regards the T5008, we could allow for aggregation of these slips the same way we allow it for T3… would this help?
~ Cameron
That would be helpful as the data entry screen now matches the actual slip.
Thanks.
General question with AFR…
We accessed for a client today and had 96 slips available on AFR! 75 or so were T5008. Our process with capital gains etc is to post a summary total from brokers gain / loss reports or similar as most of the T5008’s we see do not include the ACB. We have a couple of comments / suggestions / questions… is it possible for us to change the default option for each slip in AFR - ie: currently the default option is “create a new slip” - or is that coded into the application? We would prefer to change the default to ‘do not import’ so that if the preparer chooses to skip a bunch of slips, they will not import. Also, with large numbers of slips - T3’s and T5008 are the worst offenders - it would be nice if there was a quicker way to aggregate a large number of slips, either by using windows keystrokes (like ctrl-click or shift-click) or being able to quickly check a bunch of slips. In the case of T5008, we could aggregate them to one slip, compare the total against a gain / loss summary and then determine whether to import of ignore it. In the case above, we really don’t want 75 lines of entries on schedule 3. Any suggestions…?
I agree. If it has to be hardcoded, it might be nice to have just the T5008s and T3s set to Do not import by default. In a perfect world (like maybe next year 
), it would be nice to have an option that we can set for the default action of different types of slips from AFR.
Would it be better to have a optional default to set T3 and T5008 to “Do not import”, or would it be better to provide some way to turn all the T3 and T5008 slips to “Do not import” with one or two mouse clicks on the AFR screen?
I’m toying with sneaking this addition in for Monday’s release and want to make sure we’re taking the best intermediate step between now and the perfect world of next year…
~ Cameron
At our office we would prefer the second option (at the AFR screen) as that way we can see how many slips would be imported and make the decision at that point. And it would be good to have the choice separated between T5008s and T3s as we may want one or the other but not both.
@matthew –
Here is what I’m thinking… If we detected more than one T5008, we would add a hyperlink somewhere on the AFR screen that says “Do not import any T5008 slips”. If we detect more than one T3 slip, we would add a hyperlink somewhere on the AFR screen that says “Do not import any T3 slips”.
Clicking the links, of course, would set all the T3 or T5008 slips to “Do not import”.
Other ideas??
~ Cameron
I like that option.
I think it would work well.
Well, based on a “focus group of one”, I will proceed. 
~ Cameron
Well, I am not sure I am sold on this.
First, you are ignoring T5 slips that have the same issue of multiple slips, I am ok with the set all to do not import ; however, if you are not going to import the slips, they should be listed on a AFR summary sheet so we can see what was able to be imported when we did the download.
This is the reason why I asked for a reconciliation screen for these slips
@James and @Cameron , am thiinking this may be best addressed by allowing a spreadsheet export of AFR data…
Maybe, but I am not sure why I would want the data in another file rather than in taxcycle or doxcycle
