Chapitre 3. Guide de l’utilisateur à l’intention des fournisseurs de Régime enregistré d’épargne-études – Système du Programme canadien pour l’épargne-études et normes d’interface de données

3.1.3.1 Gestion de transfert de fichier sécurisé

Les promoteurs de REEE doivent envoyer des données par internet au système du PCEE. Ils doivent utiliser un logiciel de Gestion de transfert de fichier sécurisé (GTFS). C’est un logiciel activé par « Entrust », reconnu par EDSC comme méthode sécurisée de chiffrer des données.

3.1.3.2. Horaire des dates limites des cycles de production

EDSC fournit un horaire indiquant les dates de traitement applicables, notamment :

• les périodes de traitement;
• les dates limites de production;
• les dates de paiement.

Ces horaires sont envoyés aux promoteurs de REEE sous forme de bulletin électronique. Ils sont aussi disponibles à la page web Ressources pour les promoteurs de REEE sous l’onglet Documentation des systèmes.

3.1.3.3. Périodes de déclaration et de traitement

Chaque mois civil correspond à une période de déclaration précise au cours de laquelle les promoteurs :

• génèrent de nouvelles transactions du REEE au fur et à mesure qu’elles surviennent; et
• apportent des corrections aux transactions qui ont été rejetées ou n’ont pas été correctement soumises au système du PCEE au cours des périodes précédentes.

Chaque période de traitement commence après le dernier jour de la période de déclaration correspondante, le premier jour du mois suivant. Le système du PCEE traite les fichiers de promoteurs soumis avant 17 h, heure de l’Est, le quatrième jour ouvrable de chaque mois. Ces fichiers ne peuvent inclure aucune transaction survenue après le dernier jour de la période de déclaration correspondante.

3.3.1.1. Rapport de traitement des transactions (TE 900 et TE 911)

TE 900 est utilisé pour envoyer les types de notifications suivants :

• le traitement réussi pour les transactions de SCEE et de BEC;
• confirmation du versement de la SCEE s’appliquant aux cotisations;
• confirmation du BEC;
• raisons de refus de la SCEE et du BEC;
• autres transactions.

TE 911 est utilisé pour envoyer les types de notifications suivants :

• le traitement réussi des transactions de SEEEFCB;
• confirmation du versement de la SEEEFCB;
• raisons de refus de la SEEEFCB;
• autres transactions.

Le champ « origine de la transaction » dans un enregistrement indique pourquoi le système du PCEE a généré l’enregistrement dans le rapport de traitement des transactions. Le système du PCEE génère la plupart des TE 900 et TE 911 en réponse à des transactions de promoteur et renvoie une origine de transaction de « 0 » (initiée par le promoteur) pour ces enregistrements. Les promoteurs peuvent utiliser ces enregistrements pour déterminer l’état de traitement de chaque transaction soumise.

Les promoteurs peuvent également recevoir des enregistrements dans leurs rapports de traitement des transactions pour d’autres raisons et le champ d’origine de la transaction pour ces situations aurait un code autre que « 0 » (pas « initiée par le promoteur »). Ces enregistrements peuvent aussi contenir des données nécessaires pour mettre à jour des comptes théoriques de REEE. Par exemple :

• un agent de soutien aux promoteurs du PCEE lance une intervention manuelle;
• le système du PCEE exécute un réexamen automatique;
• l’ARC réévalue l’admissibilité d’un bénéficiaire pour les incitatifs;
• le BEC est versé pour l’année de prestation courante.

3.3.1.2. Rapport d’erreurs dans les transactions (TE 800)

TE 800 signale qu’une erreur s’est produite dans une transaction. Cela inclut l’avis que la validation a échoué ou que les renseignements soumis sont manquants, incorrects ou incorrectement formatés. L’enregistrement est rejeté et doit être corrigé et soumis de nouveau.

Les promoteurs de REEE sont responsables de corriger les erreurs et de soumettre de nouveau les transactions mises à jour au système du PCEE.

Pour plus de renseignements, se référer à l’Annexe E. Comprendre les codes d’erreurs.

3.3.1.3. Rapport d’erreurs graves (TE 850)

TE 850 signale qu’une transaction a été rejetée et qu’elle doit être corrigée et soumise de nouveau. Des erreurs graves peuvent survenir lorsque :

• des transactions avec le même NE et que l’identificateur de la transaction existe déjà (la cause la plus fréquente d’erreurs graves);
• le type d’enregistrement est invalide;
• le NE ne contient pas 15 caractères; ou
• l’identificateur de la transaction n’a pas été fourni.

Une fois que les promoteurs de REEE ont passé le test de l’industrie, leur système est moins susceptible de générer des transactions comportant des erreurs graves.

3.3.1.4. Rapport sur la validation des NAS (TE 920)

TE 920 indique que le NAS d’un bénéficiaire est non utilisable, utilisable ou lié. Ce rapport est produit après la validation mensuelle auprès de l’IAS de tous les NAS contenus dans le système du PCEE. S’il n’y a aucun problème de NAS, le promoteur ne recevra pas de rapport sur la validation des NAS. Pour plus de renseignements, se référer à la rubrique 3.4.2. Rapports de validation des NAS (TE 920).

3.3.1.5. Rapport d’enregistrement de contrat (TE 950)

TE 950 indique l’état de l’enregistrement des contrats. Les promoteurs ne devraient pas considérer un nouveau contrat comme étant « enregistrable » auprès de l’ARC avant que le système du PCEE ne retourne un TE 950 pour le contrat avec le champ « état de l’enregistrement » réglé sur « 1 » (enregistrable). Pour plus de renseignements, se référer à la rubrique 3.4.1. Transactions requises pour établir un REEE.

3.3.1.6. Rapport des résultats de traitement

Le rapport des résultats du traitement donne une ventilation de tous les types de transactions traités et le taux d’erreurs pour chaque type. Il s’agit d’un fichier PDF envoyé en anglais et en français.

3.4.1.1. Renseignements sur le contrat (100‑01)

Dans les transactions liées aux renseignements sur le contrat (100‑01), le champ « individuel ou de frère ou sœur seulement » (position 103) est le seul autre champ en plus des 7 premiers champs obligatoires pour toutes les transactions du promoteur. Ce champ doit être « 1 » (Oui) pour que le système du PCEE paie les incitatifs suivants :

• SCEE supplémentaire;
• BEC;
• SEEEFCB.

3.4.1.2. Renseignements sur le bénéficiaire (200‑03)

Les renseignements suivants sur les bénéficiaires dans les transactions 200‑03 doivent être validés par l’IAS :

• NAS;
• prénom;
• nom de famille;
• date de naissance;
• genre.

Le système du PCEE effectue une validation préliminaire des transactions 200‑03 avant d’envoyer les renseignements sur le bénéficiaire pour validation à l’IAS.

S’il est mathématiquement impossible que le NAS soit valide, le système du PCEE rejette la transaction 200‑03. Il va générer un TE 800 avec un code d’erreur 7006 (NAS non valide).

Il peut se produire des situations où le NAS a déjà été établi pour un bénéficiaire dans le système du PCEE, mais que les années de naissance ne correspondent pas. Devant une telle situation, le système du PCEE rejette la transaction 200‑03 et génère un TE 800 avec un code d’erreur 7000 (date non valide).

Si les renseignements sur le bénéficiaire dans une transaction 200‑03 passent la validation auprès de l’IAS, le système du PCEE génère un TE 900 correspondant dans le rapport de traitement des transactions. Cela informe le promoteur que le bénéficiaire a été établi avec succès dans le système du PCEE. Le promoteur par le fait même est avisé que les transactions financières peuvent être traitées avec succès pour le NAS de ce bénéficiaire. Si les renseignements du bénéficiaire dans une transaction 200‑03 échouent la validation auprès de l’IAS, le système du PCEE génère un TE 800 correspondant dans le rapport d’erreurs de transaction.

Le système du PCEE ne traite les transactions financières d’un bénéficiaire que si la transaction 200‑03 associée a été traitée avec succès et que le bénéficiaire est établi dans le système du PCEE. Autrement, toutes les transactions financières pour le NAS du bénéficiaire correspondant seront rejetées avec un code d’erreur 7001 ou 7031.

En moyenne, l’échec de la validation auprès de l’IAS des renseignements du bénéficiaire explique 80 % de toutes les transactions rejetées. Les promoteurs peuvent réduire les taux d’erreurs s’ils s’assurent de l’exactitude des renseignements sur les bénéficiaires avant de soumettre des transactions 200‑03.

Le système du PCEE traite les transactions non financières avant les transactions financières. Donc, les promoteurs peuvent soumettre leurs transactions 200‑03 dans le même fichier que les transactions financières connexes au nom d’un bénéficiaire.

Même si le NAS est correct, la 200‑03 sera rejetée avec un code d’erreur 7006 (NAS non valide) si l’un des 4 autres champs liés au NAS échoue à la validation auprès de l’IAS. Les 4 autres champs liés au NAS sont (prénom, nom, date de naissance ou genre). Le système du PCEE fait état des résultats de la validation auprès de l’IAS dans un TE 800 pour aider les promoteurs à résoudre les erreurs de transactions 200‑03 rejetées avec ce code d’erreur. Ces résultats de validation auprès de l’IAS apparaissent aux positions 76 à 80 dans un TE 800.

Par exemple, si le nom du bénéficiaire est « Katrina » auprès de l’IAS, mais que le champ du nom donné dans la transaction 200‑03 indique « Trina », le système du PCEE générera un TE 800 dans le rapport d’erreur de transaction avec :

• « NAS » comme nom du champ dans les positions 42 à 71;
• « 7006 » comme le code d’erreur dans les positions 72 à 75; et
• « 0 » dans la position 77 pour indiquer le prénom donné a échoué la validation auprès de l’IAS.

Si le NAS du bénéficiaire échoue au test de validation préliminaire au système du PCEE, les champs de validation auprès de l’IAS restent vides.

3.4.1.3. Renseignements sur le souscripteur (200‑04)

Le système du PCEE doit déterminer qu’il est mathématiquement possible que le NAS du souscripteur soit valide. Par contre, les renseignements sur le souscripteur ne sont pas validés auprès de l’IAS.

3.4.2.1.  1 – NAS est non utilisable

Les incitatifs ne seront plus versés au REEE d’un bénéficiaire tant que le promoteur n’aura pas corrigé le problème. Il aura besoin de retransmettre une transaction 200‑03 pour le bénéficiaire comprenant un NAS utilisable. Les cotisations faites au nom du bénéficiaire donnent droit à la SCEE avant que le NAS soit signalé par l’IAS. Par contre, les cotisations faites par la suite généreront un TE 900 et une raison de refus « N » (le RAS indique un problème lié au NAS) dans le rapport de traitement des transactions.

3.4.2.2.  2 – NAS est utilisable

L’état « non utilisable » a été supprimé par l’IAS pour le NAS d’un bénéficiaire faisant déjà l’objet d’un TE 920 antérieur. Par exemple, cela pourrait être le cas si l’IAS avait bloqué un NAS temporairement et l’avait rendu de nouveau utilisable à une date ultérieure.

3.4.2.3.  3 – NAS lié

Cela arrive lorsqu’un bénéficiaire reçoit un nouveau NAS pour remplacer un ancien NAS. L’ancien NAS est lié à un nouveau NAS. Par exemple, les NAS temporaires (de la série 900) expirés sont liés aux nouveaux NAS permanents. Toutes les transactions transmises sous l’ancien NAS sont rejetées. Le système du PCEE informe le promoteur en générant un TE 800 et un code d’erreur 7001 (valeur invalide) dans le rapport d’erreurs de transaction.

3.4.3.1. Rapports de surveillance de contrats non enregistrés

La loi interdit le versement d’incitatifs dans des régimes non enregistrés. Les promoteurs ont la responsabilité de s’assurer de l’état enregistrable des contrats dans les délais précisés dans la circulaire d’information IC93‑3R2 de l’ARC :

« La date d’entrée en vigueur de l’enregistrement d’un REE est la date à laquelle le régime a été conclu, si tous les renseignements requis ont été transmis par voie électronique au système du PCEE. Cela doit être fait au plus tard 60 jours après la fin de l’année civile au cours de laquelle le régime a été conclu. »

Les promoteurs peuvent également utiliser le rapport de surveillance de contrats non enregistrés pour les aider à résoudre les problèmes d’enregistrement des contrats. Ce rapport est disponible en novembre et en avril. Ce rapport est en plus du rapport d’enregistrement (TE 950).

Le PCEE envoie les contrats non enregistrés à l’ARC en octobre de l’année suivant celle pendant laquelle le contrat a été ouvert. Cela pourrait entraîner les conséquences suivantes :

• des répercussions fiscales pour les souscripteurs;
• le non‑versement d’incitatifs pour les bénéficiaires.

Les rapports de surveillance de contrats non enregistrés sont générés pour les transactions financières dans le cadre desquelles des incitatifs auraient été versés. Des rapports distincts en format Excel sont envoyés pour traiter 2 scénarios :

• transaction 100‑01 traitée avec succès;
• transaction 100‑01 manquante ou rejetée.

3.4.3.2. Rapports de surveillance d’erreurs de NAS

Des rapports de surveillance d’erreurs de NAS sont générés en avril et en octobre. Ils servent à informer les promoteurs des transactions financières rejetées à répétition (avec codes d’erreurs) au cours des 6 derniers mois. Cela est en lien avec le rejet de la transaction 200‑03 du bénéficiaire connexe.

Si la transaction 200‑03 connexe a été rejetée et le code d’erreur 7006 (NAS non valide) a été généré, les résultats de la validation de l’IAS font également l’objet de ce rapport. Ce rapport consiste en un tableur Excel contenant les données suivantes pour les transactions financières rejetées :

• NAS du bénéficiaire;
• ID du contrat;
• ID du régime type;
• code d’erreur;
• résultats de la validation auprès de l’IAS :
  • NAS;
  • prénom;
  • nom;
  • date de naissance;
  • genre.

3.4.3.3. Rapports de surveillance de la règle de 3 ans

Un incitatif ne sera pas versé si la date de la transaction pour l’enregistrement financier correspondant est plus de 3 ans avant la date à laquelle le promoteur envoie le fichier de transaction au système du PCEE. La date d’envoi est enregistrée dans l’enregistrement d’en‑tête (TE 001) du fichier soumis. Les promoteurs doivent résoudre les erreurs et soumettre de nouveau des transactions financières exactes dans la limite de 3 ans pour que les incitatifs soient versés.

Les rapports de surveillance de la règle de 3 ans sont créés en avril et en octobre. Ils ont pour but d’informer les promoteurs que les transactions financières ont été rejetées (avec des codes d’erreurs liés au NAS) et risquent potentiellement de ne pas se conformer à la règle de 3 ans au cours des prochains 4 à 10 mois. Ce rapport consiste en un tableur Excel contenant les données suivantes pour chaque transaction financière rejetée :

• NAS du bénéficiaire;
• ID du régime type;
• type de transaction;
• ID du contrat;
• date de la transaction;
• erreur du bénéficiaire :
  • NAS;
  • prénom;
  • nom;
  • date de naissance;
  • genre.

Les derniers signalements de l’IAS ne sont fournis que lorsque le code d’erreur de bénéficiaire est 7006 (NAS non valide). Sinon, les champs de l’IAS sont vides.

De nombreuses transactions financières sont rejetées parce que le bénéficiaire associé n’est pas encore établi dans le système du PCEE. Les promoteurs doivent avoir traité avec succès une transaction de renseignements sur le bénéficiaire (200‑03) avant que les incitatifs puissent être versés pour les transactions financières de ce bénéficiaire. Cela doit être fait pour chacun des bénéficiaires qui apparaissent sur le rapport.

3.5.1.1. Ordre du versement des incitatifs

Le système du PCEE verse les incitatifs selon l’ordre dans lequel les demandes d’incitatifs sont traitées avec succès. Il utilise l’approche du « premier arrivé, premier servi ». Si de multiples demandes d’incitatifs pour le même bénéficiaire sont reçues au cours d’un même mois de traitement, la transaction dont la date est la plus ancienne sera traitée en premier.

3.5.3.1. Renseignement sur les contrats, les bénéficiaires et les souscripteurs

Pour corriger les transactions avec des renseignements inexacts qui ont été traités avec succès, les promoteurs peuvent soumettre de nouvelles transactions pour :

• le contrat (100‑01);
• le bénéficiaire (200‑03);
• le souscripteur (200‑04).

3.5.3.2. Transactions de TE 400

Si une transaction de TE 400 inexacte a été traitée par le système du PCEE, le promoteur doit annuler cette transaction. Le promoteur doit par la suite soumettre une autre transaction avec les renseignements exacts. Les annulations ne sont autorisées que pour corriger les erreurs administratives sur les transactions de TE 400.

Par exemple, une cotisation de 1 000 $ a été traitée par le système du PCEE avec un montant inexact de 100 $. Le promoteur doit annuler la transaction initiale (100 $) et soumettre une nouvelle transaction avec le montant de cotisation exact (1 000 $).

Les promoteurs peuvent annuler une transaction de TE 400 inexacte en soumettant une nouvelle transaction avec les renseignements clés suivants.

La transaction transmise pour annuler une autre transaction doit comprendre un nouvel identificateur (unique) de transaction du promoteur (positions 12 à 26).

Le NE original du promoteur peut être le numéro d’entreprise d’un autre promoteur seulement si ce promoteur :

• a été fusionné au promoteur courant; ou
• acquis par ce dernier.

Dans de telles situations, les promoteurs doivent à nouveau réussir le test de l’industrie. Il doit le faire afin de démontrer que leurs systèmes sont capables d’annuler des transactions transmises par le promoteur original.

3.5.3.3. Demandes de SEEEFCB (411‑41)

Parfois, le système du PCEE traite avec succès une demande de SEEEFCB contenant une erreur administrative (par exemple, le mauvais bénéficiaire) :

• le promoteur doit soumettre une annulation de la demande de SEEEFCB (411‑41) au système du PCEE.

Ceci annule la demande d’origine et le promoteur peut alors soumettre une demande de SEEEFCB (411‑40) corrigée, si nécessaire.

3.5.4.1. Champs clés pour 400‑11

Les promoteurs peuvent demander la SCEE avec une transaction de cotisation (400‑11) en utilisant les champs clés suivants.

3.5.4.2. Champs clés de TE 900 pour la transaction 400‑11

Le système du PCEE reconnaît les transactions 400‑11 traitées avec succès avec un TE 900 dans le rapport de traitement des transactions. Voici les champs clés de TE 900 pour les transactions 400‑11.

Si le champ « subvention demandée » pour une transaction 400‑11 est « 1 » (Oui), le système du PCEE validera l’admissibilité et paiera le montant correspondant de la SCEE. Les montants de la SCEE de base et de la SCEE supplémentaire versés pour une cotisation sont déclarés aux promoteurs. Ils sont déclarés séparément dans différents champs du même TE 900. Les promoteurs doivent avoir un compte théorique pour suivre le montant total de la SCEE de base et de la SCEE supplémentaire combiné pour tous les bénéficiaires d’un REEE. Par contre, les promoteurs peuvent également tenir ces comptes au niveau du bénéficiaire.

Le système du PCEE informe les promoteurs du montant de chaque cotisation qui donne lieu à la SCEE (cotisation subventionnée) dans un TE 900 du rapport de traitement des transactions. Le promoteur doit mettre à jour le montant dans le compte théorique de cotisations subventionnées. S’il y a lieu, les promoteurs doivent calculer le montant de la cotisation restante (cotisations non subventionnées) pour mettre à jour le compte théorique des cotisations non subventionnées. Le souscripteur doit faire chaque cotisation à l’égard d’un bénéficiaire. Par contre, les promoteurs doivent maintenir les comptes théoriques pour les cotisations subventionnées et les cotisations non subventionnées au niveau du régime.

Le promoteur doit maintenir le solde du compte théorique pour les cotisations subventionnées et les cotisations non subventionnées. Dans le cas d’un transfert, le solde des 2 comptes théorique doit être inscrit sur le formulaire de transfert de REEE. Le solde du compte théorique des cotisations subventionnées est également utilisé pour calculer le montant de la SCEE qui doit être remboursé en raison d’un retrait de cotisations.

3.5.4.3. Origines des transactions pour la SCEE

3.5.4.4. Rapport de jumelage des bénéficiaires avec un motif de refus 4

Les promoteurs qui offrent la SCEE supplémentaire pourraient recevoir un rapport de jumelage des bénéficiaires avec un motif (raison) de refus 4. Ce rapport est envoyé avec leurs autres rapports mensuels. Ces rapports comprennent un enregistrement pour chaque demande de SCEE supplémentaire refusée avec une raison de refus « 4 ».

Le rapport de jumelage des bénéficiaires consiste en un tableur Excel comprenant les colonnes ci‑dessous pour chaque enregistrement :

• année de la demande;
• NAS du bénéficiaire;
• ID du contrat;
• état du nom du bénéficiaire;
• état du prénom du bénéficiaire;
• état de la date de naissance du bénéficiaire;
• NAS du responsable/conjoint (pour les particuliers responsables);
• NE du responsable (pour les responsables publics).

Pour plus de renseignements, se référer à l’Annexe F. Comprendre les raisons de refus.

3.5.4.5. Problèmes courants de 400‑11

1. Bénéficiaire non établi dans le système :
   • le bénéficiaire au nom duquel une cotisation (400‑11) a été faite n’est pas encore établi avec succès dans le système du PCEE. La transaction de cotisation est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800.

   Résolution : Pour plus d’informations, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.

2. Le contrat n’est pas établi correctement :
   • la valeur dans le champ « individuel ou de frère ou sœur seulement » d’une transaction 100‑01 aurait dû être Oui (1) plutôt que Non (0);
   • la SCEE supplémentaire est demandée au moyen d’une transaction de 400‑11, mais le versement est refusé avec une raison de refus J dans un TE 900.

Résolution : Pour plus de renseignements, se référer à la raison de refus J dans l’Annexe F. Comprendre les raisons de refus.

Avant 2018, seul le particulier responsable pouvait fournir son nom et son NAS pour demander la SCEE supplémentaire. Si l’époux ou conjoint de fait cohabitant du responsable avait plutôt fourni ses informations à titre de particulier responsable, la demande aurait été traitée avec une raison de refus « L ». Dans ces situations, le promoteur de REEE aurait dû communiquer avec le souscripteur et recueillir les renseignements du particulier responsable sur un nouveau formulaire de demande. Par la suite, le promoteur devait soumettre une transaction 511‑12 ou annuler et soumettre de nouveau la transaction 400‑11 originale avec les renseignements mis à jour.

À compter de 2018, le particulier responsable ou son époux ou conjoint de fait cohabitant, le cas échéant, peut fournir ses renseignements pour demander la SCEE supplémentaire. Le promoteur de REEE peut soumettre ces renseignements du responsable/conjoint au système et ne pas recevoir une raison de refus « L » si ces renseignements correspondent aux dossiers de l’ARC.

3.5.5.1. Champs clés pour 511‑12

3.5.5.2. Champs clés de TE 900 pour la transaction 511‑12

Chaque transaction 511‑12 traitée génère un TE 900 avec une origine de transaction de 0. Elle générera aussi 2 TE 900 avec une origine de transaction de 8 dans le rapport de traitement des transactions. Voici les champs clés de TE 900 pour la transaction 511‑12.

3.5.5.3. Alternative à l’utilisation de la transaction 511‑12

Il n’est pas obligatoire pour un promoteur d’utiliser la transaction 511‑12 pour demander la SCEE supplémentaire correspondante sur une transaction de cotisation traitée avec succès. Les promoteurs peuvent plutôt choisir d’annuler la transaction 400‑11 initiale et de soumettre une nouvelle transaction 400‑11 avec les renseignements sur le responsable/conjoint requis.

3.5.6.1. Champs clés pour 400‑24

Lors de la résiliation d’un REEE, les promoteurs devraient soumettre une transaction 400‑24 pour chaque bénéficiaire avec une demande active de BEC dans le REEE. Ils doivent entrer la valeur « 0 » (Non) dans le champ « subvention demandée ». Cela aura pour effet d’arrêter les versements du BEC dans ce REEE. Toutefois cela n’empêchera pas les bénéficiaires de recevoir des versements du BEC dans un autre REEE.

3.5.6.2. Champs clés de TE 900 pour 400‑24

Le système du PCEE reconnaît les transactions 400‑24 traitées avec succès avec un TE 900 dans le rapport de traitement des transactions. Voici les champs clés de TE 900 pour les transactions 400‑24.

3.5.6.3. Origines des transactions pour le BEC

3.5.6.4. Rapports de surveillance des retransmissions pour le BEC

Le système du PCEE peut refuser le versement pour une transaction de demande de BEC (400‑24). Par exemple, lorsque les renseignements sur le responsable ou son époux ou conjoint de fait cohabitant ne correspondent pas aux renseignements du bénéficiaire pour les critères de validation de l’ARC. Cela se produit le plus souvent lorsque l’information du bénéficiaire ne correspond pas aux dossiers de l’ARC. Cela peut se produire aussi lorsque l’enregistrement auprès de l’ARC n’a pas encore eu lieu lorsque la validation de bénéficiaire correspondant est complétée.

Les rapports trimestriels de surveillance des retransmissions pour le BEC informent les promoteurs des demandes de BEC qui ont été refusées à l’origine, mais qui peuvent maintenant réussir la validation auprès de l’ARC, et ce, en fournissant les mêmes renseignements sur le bénéficiaire et le responsable ou son époux ou conjoint de fait cohabitant. Ce rapport est un tableur Excel, présentant les colonnes suivantes pour chaque rapport d’enregistrement :

• NAS du bénéficiaire;
• ID du contrat.

3.5.6.5. Problèmes courants pour 400‑24

1. Bénéficiaire non établi dans le système :
   • le bénéficiaire pour qui le BEC a été demandé n’a pas encore été établi avec succès dans le système du PCEE. La transaction de demande de BEC (400‑24) est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.

2. Le contrat n’est pas établi correctement :
   • la valeur dans le champ « individuel ou de frère ou sœur seulement » d’une transaction 100‑01 aurait dû être « Oui » (1) plutôt que « Non » (0);
   • le BEC est demandé pour le bénéficiaire au moyen d’une transaction 400‑24, mais le versement est rejeté, générant un code d’erreur 1010 dans un TE 800.

Résolution : Pour plus de renseignements, se référer au code d’erreur 1010 dans l’Annexe E. Comprendre les codes d’erreurs.

Avant 2018, seul le particulier responsable pouvait fournir ses informations pour demander le BEC. Si l’époux ou conjoint de fait cohabitant du responsable avait plutôt fourni ses informations, le système du PCEE aurait traité la demande de BEC avec une raison de refus « L ». Le promoteur de REEE aurait dû communiquer avec le souscripteur et recueillir les renseignements du particulier responsable sur un nouveau formulaire de demande EDSC SDE 0093. Par la suite, il devrait soumettre une transaction 400‑24 pour fournir les renseignements du responsable mis à jour.

À compter de 2018, le particulier responsable ou son époux ou conjoint de fait cohabitant, le cas échéant, peut fournir ses renseignements sur le formulaire de demande EDSC SDE 0093. Le promoteur de REEE peut soumettre ces renseignements du responsable/conjoint et ne pas recevoir une raison de refus « L » si ça correspond aux dossiers de l’ARC.

À compter du 1er janvier 2022, les promoteurs devront utiliser le nouveau formulaire de demande (EDSC SDE 0107) pour les bénéficiaires âgés de 18 à 20 ans qui n’ont pas encore reçu le BEC et qui souhaitent en faire la demande. Les informations du responsable particulier ou son époux ou conjoint de fait cohabitant, le cas échéant, ne sont pas recueillies sur le formulaire EDSC SDE 0107.

3.5.7.1. Champs clés des transactions 411‑40 (demande de SEEEFCB)

Voici les champs clés pour les transactions de demande de SEEEFCB.

Date de la transaction : Les promoteurs doivent utiliser la date indiquée sur le formulaire de demande de SEEEFCB pour la date de transaction dans la demande de transaction (411‑40). Il s’agit d’une date clé utilisée pour valider les raisons de refus et les codes d’erreurs.

3.5.7.2. Champs clés de 411‑41 (annulation de la demande de SEEEFCB)

Voici les champs clés pour les transactions d’annulation de la demande de SEEEFCB.

3.5.7.3. Échéancier relatif à la SEEEFCB

Raison de refus « 3 » (âge du bénéficiaire) : Les souscripteurs ont 3 ans pour demander la SEEEFCB lorsque le bénéficiaire atteint un certain âge. Le système du PCEE enverra aux promoteurs une raison de refus « 3 » (âge du bénéficiaire) dans certaines circonstances. Cette raison de refus est transmise pour chaque demande faite après la période de 3 ans telle que spécifiée dans le tableau ci‑dessous. La date de la transaction pour une demande de SEEEFCB est la date à laquelle le souscripteur signe le formulaire de demande de SEEEFCB.

Code d’erreur 7042 : Toutes les demandes de SEEEFCB pour les bénéficiaires nés avant le 1er janvier 2006 seront rejetées avec un code d’erreur 7042.

Code d’erreur 7041 : Toutes les demandes de SEEEFCB dont la date de transaction précède le 15 août 2015 seront rejetées. Elles recevront le code d’erreur 7041.

Raison de refus D : Les promoteurs ont 3 ans pour traiter une transaction de demande de SEEEFCB avec succès. Ils doivent envoyer un fichier au système du PCEE aux fins de traitement pas plus de 3 ans après la date de transaction de la demande de SEEEFCB dans le fichier. Le système du PCEE envoie une raison de refus « D » (transaction en retard) pour les demandes de SEEEFCB traitées après ce délai.

3.5.7.4. Champs clés de TE 911 pour TE 411

Le système du PCEE reconnaîtra chaque transaction de demande de SEEEFCB (411‑40) traitée avec succès et chaque transaction d’annulation de demande de SEEEFCB (411‑41). Il le fera en envoyant aux promoteurs un TE 911 correspondant dans leur rapport mensuel de traitement des transactions.

Le système du PCEE générera aussi des enregistrements en réponse à d’autres transactions. Cela sera fait si les transactions ont une incidence sur le solde du compte de la SEEEFCB dans un REEE. Par exemple, le système du PCEE pourrait envoyer ensemble un TE 900 et un TE 911 pour la même transaction financière (TE 400). Cela se produira si le montant du PAE de la SEEEFCB ou le montant de la SEEEFCB est supérieur à 0.

Voici les champs clés de TE 911 pour des transactions de la SEEEFCB.

3.5.7.5. Problèmes courants pour les transactions de SEEEFCB (TE 411)

1. Le bénéficiaire n’est pas établi dans le système :
   • le bénéficiaire pour qui une demande de SEEEFCB (411‑40) a été faite n’a pas encore été établi avec succès dans le système du PCEE. La demande de SEEEFCB est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.

2. Le contrat n’est pas établi correctement :
   • la valeur dans le champ « individuel ou de frère ou sœur seulement » d’une transaction 100‑01 aurait dû être « Oui » (1) plutôt que « Non » (0);
   • la SEEEFCB est demandée au moyen d’une transaction 411‑40, mais la demande est rejetée, générant un code d’erreur 1010 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer le code d’erreur 1010 dans l’Annexe E. Comprendre les codes d’erreurs.

3. Formulaire de demande en retard :
   • un promoteur soumet une demande de SEEEFCB (411‑40) avec une date de transaction qui se situe à l’extérieur de l’échéancier de 3 ans;
   • la demande de SEEEFCB est traitée. Par contre, le paiement de SEEEFCB est refusé avec une raison de refus « 3 » dans un TE 911.

   Résolution : Pour plus de renseignements, se référer à la raison de refus « 3 » à l’Annexe F. Comprendre les raisons de refus. On recommande aux promoteurs d’informer les souscripteurs des échéanciers. Plus précisément, de la nécessité de remplir un formulaire de demande de SEEEFCB à l’intérieur des échéanciers requis (Pour plus de renseignements, se référer à la rubrique 3.5.7.3. Échéancier relatif à la SEEEFCB).

3.5.8.1. Champs clés des transactions 400‑13

Voici les champs clés pour les transactions PAE (400‑13).

3.5.8.2. Champs clés de TE 900 pour 400‑13

Le système du PCEE reconnaîtra chaque transaction de PAE traitée avec succès. Pour ce faire, il transmet aux promoteurs un TE 900 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.8.3. Champs clés de TE 911 pour des PAE avec un montant de SEEEFCB

Si une transaction de PAE comprend un montant de SEEEFCB supérieur à zéro, le système du PCEE reconnaîtra une transaction de PAE traitée avec succès. Pour ce faire, il enverra aux promoteurs un TE 911 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.8.4. Problèmes courants des transactions 400‑13

1. Le bénéficiaire n’est pas établi dans le système :
   • le bénéficiaire au nom duquel un PAE est versé n’a pas encore été établi dans le système du PCEE. La transaction de PAE est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer aux codes d’erreur 7001 ou 7031 dans l’Annexe E. Comprendre les codes d’erreurs.

2. Il manque des données obligatoires :
   • il manque des données dans les champs obligatoires d’une transaction de PAE. La transaction de PAE est rejetée, générant un code d’erreur 7005 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer au code d’erreur 7005 dans l’Annexe E. Comprendre les codes d’erreurs.

3.5.9.1. Champs clés des transactions 400‑14

Voici les champs clés pour un retrait de cotisations pour EPS (400‑14).

3.5.9.2. Champs clés de TE 900 pour 400‑14

Le système du PCEE reconnaîtra chaque transaction de retrait de cotisations pour EPS traitée avec succès. Il le fera en envoyant aux promoteurs un TE 900 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.9.3. Problèmes courants de 400‑14

1. Le bénéficiaire n’est pas établi dans le système :
   • le bénéficiaire identifié dans la transaction de retrait de cotisations pour EPS n’a pas encore été établi avec succès dans le système du PCEE. La 400‑14 est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer aux codes d’erreur 7001 ou 7031 dans l’Annexe E. Comprendre les codes d’erreurs.

2. Il manque des données obligatoires :
   • il manque des données dans les champs obligatoires d’une transaction de retrait de cotisations pour EPS. La 400‑14 est rejetée, générant un code d’erreur 7005 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer au code d’erreur 7005 dans l’Annexe E. Comprendre les codes d’erreurs.

3.5.10.1. Transferts partiels

Les souscripteurs doivent transférer la même proportion de chacun des soldes des comptes théoriques (les cotisations subventionnées et non subventionnées, la SCEE et les revenus accumulés), à l’exception du BEC et de la SEEEFCB.

Les souscripteurs peuvent choisir de transférer le BEC et la SEEEFCB en totalité ou en partie ou de ne pas les transférer.

3.5.10.2. Règles de transfert particulières du BEC

Un compte de BEC par bénéficiaire : Les autres incitatifs nécessitent un seul solde de compte pour tous les bénéficiaires au niveau du régime. Pour le BEC, les promoteurs doivent tenir des comptes théoriques pour chaque bénéficiaire individuel dans un REEE familial. Le transfert du BEC ne peut être transféré qu’entre les comptes théoriques de BEC d’un même bénéficiaire. Donc, les promoteurs doivent mettre à jour le compte théorique de BEC de chaque bénéficiaire individuel après un transfert.

3.5.10.3. Champs clés pour les transactions de transfert

Voici les champs clés pour les transactions de transferts (400‑19 ou 400‑23).

3.5.10.4. Champs clés de TE 900 pour les transactions de transfert

Le système du PCEE reconnaîtra chaque transaction de transfert traitée avec succès (400‑19 ou 400‑23). Pour ce faire, il enverra aux promoteurs un TE 900 dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.10.5. Champs clés de TE 911 pour un transfert de SEEEFCB

Si une transaction de transfert comprend un montant de la SEEEFCB supérieur à zéro, le système du PCEE reconnaîtra une transaction de transfert traitée avec succès. Pour ce faire, il enverra aux promoteurs un TE 911 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.10.6. Problèmes courants des transferts

1. ID de l’autre régime type est inexact :
   • un promoteur n’a pas inscrit le numéro d’identification exact du régime type du REEE dans le formulaire de transfert de REEE. L’autre promoteur saisit des renseignements inexacts pour « ID de l’autre régime type » dans son système. Lorsque l’autre promoteur transmet sa transaction de transfert au système du PCEE, la transaction est rejetée. Le système du PCEE génère un code d’erreur 1005 dans un TE 800.

   Résolution : Pour plus de renseignements, se référer au code d’erreur 1005 dans l’Annexe E. Comprendre les codes d’erreurs. Le promoteur qui a reçu un code d’erreur 1005 doit communiquer avec l’autre promoteur. Il doit obtenir le numéro d’identification exact du régime type pour son REEE. Ils devront par la suite soumettre de nouveau une nouvelle transaction de transfert au système du PCEE avec le numéro d’identification exact du régime type.

3.5.11.1. Impact des remboursements sur les paiements futurs

Droit à la SCEE : Le droit d’un bénéficiaire à la SCEE est déduit chaque fois que l’un de ces incitatifs est versé dans un REEE au nom du bénéficiaire. Toutefois, les remboursements de la SCEE se font à l’échelle du régime. Donc, le droit aux subventions des bénéficiaires individuels n’est pas rétabli par les montants remboursés de la SCEE.

SEEEFCB : Les montants de SEEEFCB remboursés ne peuvent être récupérés pour les bénéficiaires désignés dans le REEE. Les souscripteurs ne peuvent pas demander ces montants de SEEEFCB de nouveau pour les bénéficiaires concernés.

Admissibilité au BEC : Les remboursements du BEC se font à l’échelle des bénéficiaires. De plus, ils n’ont pas d’incidence sur l’admissibilité à vie au BEC du bénéficiaire. Les montants de BEC remboursés pour un bénéficiaire pourraient être reçus de nouveau pour ce bénéficiaire.

3.5.11.2. Champs clés de 400‑21

Voici les champs clés pour les transactions de remboursement d’incitatifs (400‑21).

Le BEC est propre à chaque bénéficiaire même dans un régime familial. Les promoteurs doivent donc soumettre une transaction de remboursement distincte pour chaque bénéficiaire ayant des montants de BEC dans un REEE familial. Le remboursement de tout autre incitatif se fait l’échelle du régime. Le remboursement peut être combiné à une seule transaction de remboursement (400‑21) sans fournir le NAS d’un bénéficiaire en particulier.

3.5.11.3. Raisons du remboursement

3.5.11.4. Transaction obligatoire lorsqu’un REEE est résilié

Les promoteurs doivent informer le système du PCEE lorsqu’un REEE a été résilié pour une raison quelconque. Ils le feront en soumettant une transaction de remboursement d’incitatif (400‑21) en utilisant la raison de remboursement « résiliation du contrat » (03).

Même s’il n’y a pas d’incitatifs dans un REEE lorsque le régime est résilié, la résiliation doit quand même être déclarée au système du PCEE. Le montant des incitatifs est fixé à zéro dans la transaction 400‑21.

3.5.11.5. Champs clés de TE 900 pour 400‑21

Le système du PCEE reconnaîtra chaque transaction de remboursement traitée avec succès (400‑21). Il le fera en envoyant aux promoteurs un TE 900 dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants :

3.5.11.6. Champs clés de TE 911 pour un remboursement de SEEEFCB

Si une transaction de remboursement comprend un montant de la SEEEFCB supérieur à zéro, le système du PCEE reconnaîtra une transaction de remboursement traitée avec succès. Il le fera en envoyant aux promoteurs un TE 911 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.11.7. Problèmes courants de 400‑21

1. Les promoteurs n’avisent pas le système du PCEE des résiliations :
   • un souscripteur a transféré tous les fonds d’un REEE à un autre REEE administré par un autre promoteur et met fin au régime. Le promoteur cédant n’a transmis qu’une transaction de transfert de sortie (TE 400‑23) au système du PCEE. Ce promoteur n’envoie pas aussi une transaction obligatoire de remboursement (TE 400‑21) avec une raison de remboursement « 03 » (résiliation de contrat). Lors d’un examen de conformité par le PCEE, ce REEE pourrait être signalé comme un problème de conformité.

   Résolution : Le promoteur du REEE cédant doit soumettre une transaction de remboursement (400‑21), avec une raison de remboursement « 03 » (résiliation de contrat). Il le fait après avoir mis à jour tous les comptes théoriques pour ramener les soldes à 0. Tous les montants de remboursement seront à 0 dans cette transaction.

2. L’utilisation des annulations au lieu des remboursements :
   • un souscripteur se rend compte que certaines cotisations au nom d’un bénéficiaire n’ont pas donné droit à la SCEE en raison de la limite annuelle (raison de refus « 1 »). Le souscripteur souhaite retirer les cotisations non subventionnées (les cotisations qui n’ont pas donné lieu à la subvention). Le souscripteur voudrait que le promoteur annule toutes les cotisations non subventionnées pour éviter de rembourser la SCEE. Puisqu’il ne s’agit pas d’une erreur administrative, le promoteur ne peut pas annuler les cotisations non subventionnées.

   Résolution : Le promoteur doit informer le souscripteur qu’il ne peut rien faire pour ce qui est des cotisations non subventionnées de cette année‑là. Le promoteur doit aussi expliquer que la limite annuelle de la SCEE par bénéficiaire s’applique à tous les REEE. Le promoteur doit aussi aider le souscripteur à planifier ses cotisations pour les années subséquentes.

3. L’utilisation des remboursements au lieu des annulations :
   • en raison d’une erreur administrative commise par le promoteur, une transaction de cotisation (400‑11) donnant lieu à la SCEE a été transmise pour le mauvais bénéficiaire d’un REEE familial. Le promoteur soumet une transaction de remboursement (400‑21) pour rembourser le montant de la SCEE reçu pour le mauvais bénéficiaire. Ensuite, le promoteur soumet une nouvelle transaction de cotisation pour le bon bénéficiaire. Les limites de cotisations au REEE du bénéficiaire original ne sont pas rétablies après une transaction de remboursement. Même chose pour les limites à vie de la SCEE et le droit à la SCEE.

   Résolution : Le promoteur aurait dû annuler la transaction 400‑11 plutôt que de soumettre une transaction de remboursement. Pour corriger le problème, le promoteur doit maintenant annuler la transaction de cotisation originale et annuler la transaction de remboursement.

3.5.12.1. Champs clés des transactions 400‑22

Voici les champs clés pour les transactions de rajustement au moment de la résiliation (400‑22).

3.5.12.2. Champs clés de TE 900 pour 400‑22

Le système du PCEE reconnaîtra chaque transaction de rajustement traitée avec succès (400‑22). Il le fera en envoyant aux promoteurs un TE 900 dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.12.3. Champs clés de TE 911 pour un rajustement de SEEEFCB

Si une transaction de rajustement au moment de résiliation comprend un montant de la SEEEFCB supérieur à 0, le système du PCEE reconnaîtra une transaction de rajustement traitée avec succès. Il le fera en envoyant aux promoteurs un TE 911 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

3.5.12.4. Retrait de cotisations après une perte

Ordre des pertes : Les promoteurs doivent appliquer les pertes d’abord aux revenus et ensuite, aux cotisations. Une fois que toutes les cotisations dans le REEE sont épuisées, toute perte résiduelle doit être appliquée proportionnellement aux incitatifs restants. Cela veut dire que les pertes seront attribuées proportionnellement entre les incitatifs fédéraux et provinciaux restants dans le REEE.

Test de la juste valeur marchande : Lorsqu’un souscripteur demande un retrait des cotisations pour une raison quelconque, les promoteurs doivent déterminer la juste valeur marchande du REEE. Il doit s’assurer qu’elle est suffisamment élevée pour le retrait demandé. Ceci s’applique même lorsque le REEE n’est pas résilié et inclut également les montants de retrait de cotisations pour EPS.

Limite des retraits de cotisations : Les promoteurs doivent soustraire les incitatifs du solde des comptes théoriques de la juste valeur marchande pour déterminer le montant maximal du retrait de cotisations.

Par exemple, à la résiliation d’un REEE, un souscripteur demande le remboursement de toutes les cotisations. La liste ci‑dessous présente les comptes théoriques et la juste valeur marchande du REEE à ce moment‑là :

• juste valeur marchande du REEE : 2 600 $;
• cotisations : 2 500 $;
• SCEE : 1 000 $;
• BEC : 600 $;

Dans cet exemple, les incitatifs combinés des comptes théoriques s’élèvent à 1 600 $, ce qui signifie que la limite des retraits de cotisations est de 1 000 $ (soustraire 1 600 $ à 2 600 $). Par conséquent, le promoteur ne peut retourner que 1 000 $ de cotisations au souscripteur après avoir remboursé tous les incitatifs restants dans le REEE.