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

De : Emploi et Développement social Canada

Avertissement : Promoteurs de REEE

Les renseignements qui figurent sur cette page sont de nature technique et sont destinés aux promoteurs de Régime enregistré d’épargne‑études (REEE) et du Programme canadien pour l’épargne‑études et sont de nature technique. Pour accéder à de l’information plus générale, veuillez consulter la section REEE.

Sur cette page

Format substitut

Une version PDF du guide de l’utilisateur à l’intention des fournisseurs de régimes enregistrés d’épargne‑études est disponible sur la page d’index.

Liste des acronymes

BEC
Bon d’études canadien
EDSC
Emploi et Développement social Canada
NID
Normes d’interface de données
PCEE
Programme canadien pour l’épargne‑études
REEE
Régime enregistré d’épargne‑études
SCEE
Subvention canadienne pour l’épargne‑études
SEEAS
Subvention pour l’épargne‑études Avantage Saskatchewan
SEEEFCB
Subvention pour l’épargne‑études et l’épargne‑formation de la Colombie‑Britannique
TE
Type d’enregistrement
TT
Type de transaction

Introduction

Une fois que les formulaires appropriés sont remplis et signés, les promoteurs doivent transmettre les renseignements essentiels électroniquement au système du Programme canadien pour l’épargne‑études (PCEE). Ils doivent aussi faire parvenir les demandes d’incitatifs qui sont administrés par Emploi et Développement social Canada (EDSC). Ceci est généralement traité par les services administratifs d’un promoteur de régimes enregistrés d’épargne‑études (REEE) ou par un fournisseur de service.

Le promoteur de REEE joue un rôle important en veillant à ce que le système du PCEE reçoive les renseignements nécessaires pour :

  • enregistrer les régimes d’épargne‑études auprès de l’Agence du revenu du Canada (ARC);
  • traiter les transactions pour les incitatifs suivants administrés par EDSC :
    • Subvention canadienne pour l’épargne‑études (SCEE);
    • Bon d’études canadien (BEC);
    • Subvention pour l’épargne‑études Avantage Saskatchewan (SEEAS);
    • Subvention pour l’épargne‑études et l’épargne‑formation de la Colombie‑Britannique (SEEEFCB).

Ce chapitre donne un aperçu du système du PCEE. Il fournit aussi des détails sur le genre de renseignements échangés par les promoteurs de REEE et par le système du PCEE.

Pour plus de renseignements, se référer à l’Annexe C pour les acronymes et termes utilisés dans ce guide.

3.1 Aperçu du système du PCEE

3.1.1. Qu’est‑ce que le système du PCEE

Le système du PCEE est une application électronique d’EDSC qui permet d’offrir des incitatifs à l’épargne‑études fédéraux et provinciaux qui sont administrés par EDSC. Le système du PCEE permet l’échange de renseignement électronique avec les partenaires suivants :

  • promoteurs de REEE;
  • Immatriculation aux assurances sociales (IAS);
  • Agence du revenu du Canada (ARC).

Lorsqu’un souscripteur ouvre un régime d’épargne‑études (REE), le promoteur de REEE aide le souscripteur à remplir les formulaires appropriés. Le promoteur doit recueillir 2 catégories de renseignements non financiers :

  • renseignement sur le contrat lui‑même;
  • renseignement sur le souscripteur et bénéficiaire.

Le promoteur de REEE soumet les transactions initiales d’un nouveau REE au système du PCEE. Pour plus de renseignements, se référer à la rubrique 3.4.1. Transactions requises pour établir un REEE.

Dès que ces renseignements sont validés, le contrat peut être enregistré auprès de l’ARC pour devenir un REEE. Le bénéficiaire sera alors établi dans le système du PCEE et les transactions financières peuvent ensuite être traitées pour le bénéficiaire, telles que :

  • les cotisations;
  • les demandes d’incitatifs;
  • les remboursements d’incitatifs;
  • les paiements d’aide aux études (PAE);
  • etc.

Les renseignements échangés entre le promoteur de REEE et le système du PCEE permettent à EDSC de :

  • vérifier les renseignements du contrat, du souscripteur et du bénéficiaire;
  • présenter à l’ARC des demandes d’enregistrement de REE;
  • vérifier les renseignements sur le responsable ou son époux ou conjoint de fait cohabitant;
  • confirmer l’admissibilité aux incitatifs administrés par EDSC;
  • surveiller les transactions liées aux limites pour chaque bénéficiaire; et
  • suivre les paiements et les remboursements d’incitatifs administrés par EDSC.

Le système du PCEE génère également des rapports concernant les programmes provinciaux désignés administrés par EDSC pour les gouvernements provinciaux suivants :

  • Gouvernement de la Saskatchewan;
  • Gouvernement de la Colombie‑Britannique.

3.1.2. Terminologie du système du PCEE

Certains termes clés liés au système du PCEE sont utilisés dans ce chapitre et dans le présent guide.

Numéro d’entreprise (NE) : Le numéro d’entreprise (NE) est un code de 15 caractères alphanumériques. Il identifie le promoteur de REEE ou le mandataire autorisé à soumettre des transactions au système du PCEE.

Normes d’interface de données (NID) : Les Normes d’interface de données (NID) est un document qui offre des précisions quant à la procédure de formatage et à la soumission électronique des transactions au système du PCEE. Pour plus de renseignements, se référer à la rubrique 3.2. Normes d’interface de données (NID).

Type d’enregistrement (TE) : Le NID utilise une série de types d’enregistrements (TE) pour classer les renseignements. Ces renseignements sont échangés entre le système du promoteur de REEE et le système du PCEE. Par exemple, un TE 100 identifie un enregistrement qui décrit les renseignements sur le contrat d’un REEE. Pour plus de renseignements, se référer à la rubrique 3.2.3. Types d’enregistrements et types de transactions.

Type de transaction (TT) : Un nombre à 2 chiffres identifie les types d’enregistrement (TE) des transactions du promoteur dans des types de transactions distinctes (TT). Par exemple, une transaction financière qui rapporte une cotisation à un REEE peut être appelée une transaction 400‑11. Pour plus de renseignements, se référer à la rubrique 3.2.3. Types d’enregistrements et types de transactions.

3.1.3. Cycle de traitement mensuel du système du PCEE

Le système du PCEE traite les transactions soumises par les promoteurs de REEE et paie les incitatifs correspondants sur une base mensuelle.

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 Canada.ca/REEEressources 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.1.4. Aperçu du processus

L’aperçu suivant décrit le traitement des transactions d’un REEE par le système du PCEE :

  1. promoteur de REEE : soumet par voie électronique, les transactions au système du PCEE pour la période de déclaration courante. Les transactions non financières sont utilisées pour demander l’enregistrement du REE. D’autres transactions sont associées aux incitatifs administrés par EDSC. Pour plus de renseignements, se référer à la rubrique 3.2.3. Types d’enregistrements et types de transactions et 3.4. Établir un REEE;
  2. système du PCEE : récupère les transactions soumises et les télécharge dans le système du PCEE;
  3. système du PCEE : vérifie les transactions non financières :
    • confirme que les champs obligatoires sont remplis et que le format est adéquat selon les NID (par exemple : les champs de date doivent être présentés selon le format AAAAMMJJ);
    • vérifie la conformité aux règles de fonctionnement (par exemple : l’âge du bénéficiaire) et effectue la validation du numéro d’assurance sociale (NAS);

    Validation du NAS (pour plus de renseignements, se référer à la rubrique 3.4.1.2. Renseignements sur le bénéficiaire (200‑03)

    Le système du PCEE effectue une validation initiale du NAS avant de soumettre à l’IAS les autres renseignements sur le NAS aux fins de validation.

    Si le NAS du bénéficiaire échoue la vérification initiale du PCEE, la transaction est rejetée et le promoteur reçoit un TE 800 dans le rapport d’erreur de transaction.

    Si le NAS du bénéficiaire réussit la vérification initiale du PCEE, les renseignements sur le bénéficiaire sont transmis à l’IAS aux fins de validation.

    Si la validation par l’IAS échoue, la transaction est rejetée et le promoteur reçoit un TE 800 dans le rapport d’erreur de transaction signalant les champs qui ne correspondent pas.

    Si la validation par l’IAS est réussie, le bénéficiaire est ajouté à la base de données du système du PCEE et un TE 900 dans le rapport de traitement des transactions est transmis au promoteur de REEE.

  4. système du PCEE : après la validation de tous les renseignements sur le contrat, le PCEE communique avec l’ARC pour demander l’enregistrement du REE;
  5. système du PCEE : traite les transactions ayant une incidence sur les incitatifs administrés par EDSC. Si la transaction renferme une demande de BEC ou de SCEE supplémentaire, le système du PCEE confirme les renseignements suivants auprès de l’ARC :
    • les renseignements sur le responsable ou son époux ou conjoint de fait cohabitant correspondent aux dossiers de l’ARC pour le bénéficiaire;
    • le bénéficiaire est une personne à la charge du responsable; et
    • le bénéficiaire est admissible au BEC ou à la SCEE supplémentaire;
  6. système du PCEE : génère des rapports aux promoteurs de REEE, les informant des résultats du cycle de production y compris le paiement ou le remboursement des incitatifs administrés par EDSC;

    Rapports du système du PCEE (pour plus de renseignements, se référer à la rubrique 3.3.1. Rapports mensuels du système du PCEE)

    Le promoteur de REEE reçoit une confirmation de l’état de chaque transaction soumise au système du PCEE. Cette confirmation provient des rapports mensuels suivants :

    • rapport d’erreurs (TE 800) : indique que la validation a échoué ou que les renseignements soumis sont manquants, incorrects ou présentés dans le mauvais format. La transaction doit être corrigée et soumise de nouveau;
    • rapport d’erreurs graves (TE 850) : identifie les erreurs graves et indique que l’enregistrement est rejeté et doit être corrigé et soumis de nouveau;
    • rapport de traitement des transactions (TE 900 + TE 910 + TE 911) : atteste que la transaction a été traitée avec succès;
    • rapport de validation du NAS (TE 920) : indique que lors de la validation du NAS du bénéficiaire auprès de l’IAS, le NAS était non utilisable, utilisable ou lié;
    • rapport d’enregistrement de contrat (TE 950) : atteste que le contrat est admissible à l’enregistrement.
  7. système du PCEE : selon les résultats du traitement de renseignement financier :
    • mets à jour les comptes du bénéficiaire, y compris le montant global des incitatifs administrés par EDSC, versés à l’égard de chaque bénéficiaire;
    • mets à jour les renseignements du régime type, y compris le montant total versé pour les incitatifs administrés par EDSC. Cela se produit pour chaque régime type afin d’identifier et de suivre les obligations liées à ces incitatifs.
  8. système du PCEE : envoie un bulletin électronique au promoteur de REEE. Ce bulletin l’avise qu’il peut télécharger les fichiers de rapports en utilisant le logiciel de GTFS;
  9. système du PCEE : effectue un paiement dans le compte du promoteur de REEE;
  10. promoteur de REEE : utilise le rapport de traitement des transactions pour mettre à jour les comptes liés au contrat. Cela pourrait inclure :
    • des renseignements concernant l’état de l’enregistrement du contrat;
    • les paiements ou remboursements d’incitatifs administrés par EDSC;
    • les transferts;
    • les PAE;
  11. promoteur de REEE : utilise le rapport d’erreurs et le rapport d’erreurs graves pour identifier les transactions rejetées. Par la suite, il pourra soumettre les transactions requises pour corriger ces erreurs.

3.2. Normes d’interface de données (NID)

3.2.1. Qu’est‑ce que les NID

Les NID précisent comment les promoteurs de REEE et le système du PCEE échangent des renseignements électroniques en décrivant :

  • les procédures de formatage et de présentation des transactions; et
  • comment le système du PCEE valide et traite les transactions.

Les NID sont disponibles à la page Web Canada.ca/REEEressources sous l’onglet Documentation des systèmes. Les modifications aux NID sont communiquées aux promoteurs de REEE par l’entremise d’un bulletin électronique.

3.2.2. Qu’est‑ce qu’un enregistrement

Les promoteurs de REEE envoient des fichiers de transactions au système du PCEE aux fins de traitement. Par la suite, le système du PCEE renvoie les fichiers de rapport aux promoteurs. Les 2 fichiers peuvent contenir un nombre indéterminé d’enregistrements.

Un enregistrement consiste en :

  • une série pouvant contenir jusqu’à 500 caractères sur 1 ligne;
  • un ensemble de champs dans des groupes de caractères adjacents; et
  • des renseignements détaillés sur 1 transaction.

3.2.3. Types d’enregistrements et types de transactions

Les champs prévus pour le type d’enregistrement (TE) et le type de transaction (TT) permettent de classer les transactions des promoteurs. Par exemple, les transactions de PAE peuvent être appelées les transactions « 400‑13 ». On les appelle ainsi car elles ont un TE de 400 (position 1 à 3) et un TT de 13 (position 42 à 43).

Enregistrements de transaction selon le type d’enregistrement (TE) et le type de transaction (TT) :

  • transactions non financières nécessaires pour enregistrer un REEE :
    • 100‑01 : renseignements sur le contrat;
    • 200‑03 : renseignements sur le bénéficiaire;
    • 200‑04 : renseignements sur le souscripteur.
  • transactions ayant une incidence financière sur les REEE :
    • 400‑11 : cotisation (et demande possible de la SCEE);
    • 400‑13 : PAE;
    • 400‑14 : retrait des cotisations pour EPS;
    • 400‑19 : transfer d’entrée (contrat);
    • 400‑21 : remboursement d’incitatif;
    • 400‑22 : rajustement de résiliation;
    • 400‑23 : transfer de sortie (contrat);
    • 400‑24 : demande de BEC;
    • 410‑30 : demande de SEAAS;
    • 410‑31 : annulation de la demande de SEEAS;
    • 411‑40 : demande de SEEEFCB;
    • 411‑41 : annulation de la demande de SEEEFCB;
    • 511‑12 : renseignements sur le responsable/conjoint.
  • comptes rendus sommaires :
    • 700‑aucune : rapport sommaire des transactions (juste valeur marchande des REEE).

3.2.4. Champs communs dans les transactions des promoteurs

Les 7 premiers champs (position 1 à 68) sont communs et obligatoires pour toutes les transactions des promoteurs. Les règles de validation des NID identifient d’autres champs obligatoires pour chaque type d’enregistrement.

Tableau 1 : Champs communs et obligatoires pour toutes les transactions des promoteurs
Nom de champ Position Notes
Type d’enregistrement 1 à 3 Identifie le type d’enregistrement.
Date de la transaction 4 à 11 La date à laquelle un événement a eu lieu Format : AAAAMMJJ.
ID de transaction du promoteur 12 à 26 Un numéro unique attribué par le promoteur afin de suivre chaque transaction.
NE du promoteur 27 à 41 Un numéro unique attribué à chaque promoteur pour le système du PCEE.
Type de transaction 42 à 43 Utilisé pour classer les types de transactions des promoteurs.
ID du régime type 44 à 53 Un numéro unique attribué par l’ARC à chaque régime type.
ID du contrat 54 à 68 Un numéro unique attribué par le promoteur pour l’identification d’un REEE.

Le système du PCEE rejette toutes les transactions des promoteurs qui n’incluent pas les renseignements obligatoires. Selon le champ manquant, le système du PCEE va générer soit :

  • un TE 850 dans le rapport d’erreurs graves; ou
  • un TE 800, générant un code d’erreur 7005 dans le rapport d’erreurs de transaction.

3.2.5. Type d’enregistrements dans les rapports du système du PCEE

Le type d’enregistrement (TE) permet de classer les enregistrements en catégories dans les fichiers de rapport générés par le système du PCEE. Le tableau suivant présente les types d’enregistrements clés employés dans ces rapports. Pour plus de renseignements, se référer à la rubrique 3.3. Rapports du PCEE.

Tableau 2 : Types d’enregistrements clés
Fichiers de rapport du système du PCEE TE Fréquence
Rapport d’erreurs de transaction (.err) 800 Mensuelle
Rapport d’erreurs graves (.ser) 850 Mensuelle
Rapport de traitement des transactions (.pro) 900, 910 et 911
(se référer au Tableau 3)
Mensuelle
Rapport sur la validation des NAS (.svr) 920 Mensuelle
Rapport d’enregistrement de contrat (.reg) 950 Mensuelle
Rapport de références (.ref) 960 Tous les jours
Tableau 3 : Types d’enregistrements dans le rapport de traitement des transactions (.pro)
Types d’enregistrements TE Fréquence
Transactions financières 900 Mensuelle
Transactions de la SEEAS 910 Mensuelle
Transactions de la SEEEFCB 911 Mensuelle

3.2.6. Conformité du système et test de l’industrie

Toutes les institutions financières participantes offrant des incitatifs à l’épargne‑études administrés par EDSC doivent s’assurer que leur système peut :

  • communiquer avec le système du PCEE; et
  • se conformer aux NID.

Cela est fait dans le cadre du processus d’inscription des promoteurs de REEE.

La procédure du test de l’industrie obligatoire est très importante. Elle aide les organisations financières à s’assurer que leur système est prêt à signaler des transactions au système du PCEE. Elle aide aussi à s’assurer qu’ils peuvent recevoir des renseignements du système du PCEE.

Les institutions financières transmettent des fichiers de test transmis par voie électronique au système du PCEE. Avant qu’un promoteur de REEE ne puisse soumettre des fichiers aux fins de traitement., il doit recevoir une note de passage d’au moins 90 %.

Le Guide des tests de l’industrie du PCEE est disponible à la page Web Canada.ca/ressourcesREEE sous l’onglet Documentation des systèmes.

3.3. Rapports du PCEE

3.3.1. Rapports mensuels du système du PCEE

Le système du PCEE fait rapport de l’état de traitement de chaque transaction de promoteur dans les rapports mensuels.

Tableau 4 : État de traitement de chaque transaction de promoteur dans les rapports mensuels
État TE Rapport mensuel
Traitées
  • TE 900 (SCEE et BEC)
  • TE 910 (SEEAS)
  • TE 911 (SEEEFCB)
Rapport de traitement des transactions
Rejetées TE 800 Rapport d’erreurs de transaction
TE 850 Rapport d’erreurs graves

Une « transaction traitée » dans ce chapitre est une transaction qui a été traitée avec succès par le système du PCEE. Cela comprend les demandes d’incitatifs pour lesquelles les versements d’incitatifs ont été refusés. Le système du PCEE génère une raison de refus en réponse à une demande d’incitatif lorsque le plein montant de l’incitatif n’est pas payé.

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

Une « transaction rejetée » dans ce chapitre signifie que la transaction n’a pas été traitée par le système du PCEE. Cela pourrait se produire pour l’une des raisons suivantes :

  • une erreur dans la transaction a généré un code d’erreur;
  • une erreur grave dans la transaction a généré un type d’erreur.

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

3.3.1.1. Rapport de traitement des transactions (TE 900, TE 910 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 910 est utilisé pour envoyer les types de notifications suivants :

  • le traitement réussi des transactions de SEEAS;
  • confirmation du versement de la SEEAS;
  • raisons de refus de la SEEAS;
  • 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, TE 910 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.3.2. Rapport de références (TE 960)

Le Service d’enregistrement des naissances du gouvernement de l’Ontario permet aux parents de nouveau‑nés de l’Ontario :

  • d’enregistrer en ligne la naissance d’enfants nouveau‑nés;
  • de demander un certificat de naissance;
  • de présenter une demande de numéro d’assurance sociale (NAS); et
  • de présenter une demande de prestations fédérales et provinciales pour enfants, y compris l’Allocation canadienne pour enfants.

Ce service comprend maintenant la possibilité de demander le service de références pour l’épargne‑études. Cela favorise les efforts des gouvernements fédéral et provincial pour encourager et soutenir le fait d’épargner tôt et à long terme pour les études postsecondaires d’un enfant.

Lors de l’inscription en ligne de la naissance d’un enfant, les parents de nouveau‑nés de l’Ontario peuvent demander à être contactés par un promoteur de REEE participant de leur choix. Ils pourront alors s’informer et ouvrir un REEE, et demander le BEC et la SCEE pour leur enfant.

Lorsqu’il choisit de participer, le parent :

  • consens à ce que ses renseignements personnels soient partagés;
  • valide ses coordonnées; et
  • donne son consentement à être contacté par le promoteur de REEE qu’il a choisi.

Après avoir confirmé l’enregistrement de la naissance, ServiceOntario transmet les renseignements de la personne référée au système du PCEE. Ce dernier traite ces renseignements et les fournit au promoteur sélectionné dans un rapport de références quotidien (TE 960). Les promoteurs recevront un rapport de références tous les jours, qu’il y ait ou non des rapports de références à envoyer. Un rapport de références vide contient uniquement l’enregistrement d’en‑tête et l’enregistrement de fin.

3.3.3. Rapports de surveillance du PCEE

Certains promoteurs peuvent également recevoir des rapports de surveillance en format Excel, en plus des rapports décrits dans les NID. Ces rapports sont en fonction des résultats de la surveillance. Les promoteurs individuels sont informés par courriel lorsque ces rapports Excel peuvent être téléchargés par l’entremise du logiciel de GTFS.

Tableau 5 : Rapports de surveillance et leur objectif
Rapport de surveillance du PCEE Objectif Mois du rapport
Contrats non enregistrés
Pour plus de renseignements, se référer à la rubrique 3.4.3.1. Rapports de surveillance de contrats non enregistrés
Identifie les contrats qui risquent de ne pas être jugés « enregistrables » par le système du PCEE.
  • Novembre
  • Avril
Erreurs de NAS
Pour plus de renseignements, se référer à la rubrique 3.4.3.2. Rapports de surveillance d’erreurs de NAS
Identifie les transactions financières rejetées à répétition (avec des codes d’erreurs). Plus précisément, celle pour lesquelles le bénéficiaire associé n’est pas encore établi dans le système du PCEE.
  • Avril
  • Octobre
Règle de 3 ans
Pour plus de renseignements, se référer à la rubrique 3.4.3.3. Rapports de surveillance de la règle de 3 ans
Identifie les transactions financières qui ont été rejetées (avec des codes d’erreurs liés au NAS), mais qui n’ont pas été corrigées. Ce sont plus précisément des transactions qui risquent d’échouer la règle des 3 ans au cours des prochains 4 à 10 mois.
  • Avril
  • Octobre
Retransmission des BEC
Pour plus de renseignements, se référer à la rubrique 3.5.6.4. Rapports de surveillance des retransmissions pour le BEC
Identifie les demandes de BEC qui ont été refusées (non rejetées avec des codes d’erreurs). Le BEC pourrait être payé si les demandes sont soumises de nouveau. Cette situation survient lorsque l’ARC ou le système du PCEE ont depuis mis à jour leurs renseignements.
  • Janvier
  • Avril
  • Juillet
  • Octobre
Surveillance mensuelle Résume les erreurs pour les promoteurs ayant des taux d’erreurs de plus de 10 %, ou des montants de cotisations erronés de plus de 750 000 $. Mensuellement (si nécessaire)

3.4. Établir un REEE

Le promoteur de REEE doit recueillir les renseignements et les inscrire dans le système du promoteur de REEE. Ce dernier pourra alors soumettre les transactions électroniques requises au système du PCEE afin d’établir un REEE.

3.4.1. Transactions requises pour établir un REEE

Le système du PCEE nécessite 3 transactions distinctes pour chaque REE afin d’enregistrer le contrat.

Transaction 1 : Renseignements sur le contrat (100‑01)

Cela comprend des renseignements tels que :

  • la date d’ouverture du contrat;
  • le numéro du contrat;
  • le numéro du régime type;
  • le NE de l’institution financière;
  • etc.

La transaction 100‑01 établit le contrat dans le système du PCEE et indique si le régime est un régime « individuel ou de frère ou sœur seulement ».

Transaction 2 : Renseignements sur le bénéficiaire (200‑03)

Transaction 3 : Renseignements sur le souscripteur (200‑04)

Une fois que les 3 transactions ont été traitées avec succès par le système du PCEE :

  • le promoteur reçoit un TE 950 dans le rapport d’enregistrement du contrat. Le champ « état de l’enregistrement » sera réglé à « 1 » (enregistrable); et
  • le système du PCEE envoie une demande à l’ARC pour enregistrer le REE.

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;
  • SEEAS;
  • SEEEFCB.
3.4.1.1.1. Problèmes courants de 100‑01
  1. Contrat établi incorrectement :
    • 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 400‑11, mais le versement est refusé (raison de refus J) dans un TE 900.

    Résolution : Pour plus de renseignements, se référer au code de refus J dans l’Annexe F. Comprendre les codes de refus.

  2. Contrat établi incorrectement :
    • 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);
    • l’un des incitatifs suivants est demandé au moyen de la transaction présentée, mais est rejeté avec un code d’erreur 1010 dans un TE 800 :
      • SCEE supplémentaire (511‑12);
      • BEC (400‑24);
      • SEEAS (410‑30);
      • SEEEFCB (411‑40).

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

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;
  • sexe.

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 sexe). 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 à la position 76 à 80 dans un TE 800.

Tableau 6 : Résultats de validation auprès de l’IAS
Nom de champ dans le TE 800 Position Résultats de validation auprès de l’IAS
NAS 76
  • 0 – Échec de la validation auprès de l’IAS
  • 1 – Réussite de la validation auprès de l’IAS
Prénom 77
  • 0 – Échec de la validation auprès de l’IAS
  • 1 – Réussite de la validation auprès de l’IAS
Nom 78
  • 0 – Échec de la validation auprès de l’IAS
  • 1 – Réussite de la validation auprès de l’IAS
Date de naissance 79
  • 0 – Échec de la validation auprès de l’IAS
  • 1 – Réussite de la validation auprès de l’IAS
  • 2 – Échec‑année et mois exacts
  • 3 – Échec‑année et jour exacts
Sexe 80
  • 0 – Échec de la validation auprès de l’IAS
  • 1 – Réussite de la validation auprès de l’IAS

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 la position 42 à 71;
  • « 7006 » comme le code d’erreur dans la position 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.2.1. Problèmes courants de 200‑03
  1. Échec de l’un ou l’autre des 5 champs de NAS :
    • les renseignements sur le NAS d’un bénéficiaire dans une transaction 200‑03 échouent à la validation auprès de l’IAS. Par exemple :
      • un surnom est utilisé dans l’IAS plutôt que le prénom officiel (« Bob » plutôt que « Robert »);
      • le prénom et le nom de famille sont inversés;
      • le jour et le mois sont inversés dans la date de naissance.
    • le système du PCEE rejette la transaction 200‑03 avec un code d’erreur 7006 (NAS non valide). Cela empêche également le système du PCEE de traiter les transactions financières pour ce bénéficiaire.

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

  2. D’autres transactions sont rejetées :
    • d’autres transactions sont transmises pour un bénéficiaire qui n’est pas encore établi dans le système du PCEE. Les transactions du bénéficiaire concerné sont rejetées et un code d’erreur 7001 ou 7031 est généré dans le rapport d’erreurs de transaction.

    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.

  3. Problèmes liés à la protection des renseignements personnels pour le parent ayant la garde :
    • le père d’un bénéficiaire communique avec le centre d’appels du PCEE pour connaître le droit à subvention non utilisé de ce bénéficiaire. Où, seulement la mère du bénéficiaire est désignée dans le champ prévu pour le nom du parent ayant la garde. C’est de la position 411 à 440 dans la transaction 200‑03. Le PCEE ne peut donc divulguer des informations au père pour des raisons de confidentialité.

    Résolution : Le promoteur pourrait envoyer une autre transaction 200‑03 au système du PCEE avec le nom du père dans le champ du nom du parent ayant la garde. L’autre option, si le système du promoteur le permet, serait de fusionner le nom du père et de la mère dans le même champ du nom du parent ayant la garde. Par la suite il peut le soumettre au système du PCEE dans une nouvelle transaction 200‑03.

  4. Bénéficiaire a un seul nom :
    • bien que ce ne soit pas un problème fréquent, il se peut que le bénéficiaire n’ait qu’un nom (le prénom et le nom de famille forment un seul et même nom). Dans le passé, intervention manuelle était requise afin d’établir le bénéficiaire dans le système du PCEE.

    Résolution : Le système du PCEE permet maintenant de laisser le champ « prénom » vide. Si le système du promoteur ne permet pas de laisser un champ vide, le promoteur peut inscrire un point (.), un trait d’union (‑), ou un trait de soulignement (_).

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. Rapports de validation des NAS (TE 920)

Il se peut que le NAS d’un bénéficiaire devienne non utilisable après la validation et l’établissement réussis du bénéficiaire dans le système du PCEE. Cela affectera les nouvelles transactions financières. Voici des explications possibles :

  • la mort du bénéficiaire;
  • un NAS temporaire (de la série 900) annulé ou expiré;
  • un NAS utilisé frauduleusement.

Chaque mois, le système du PCEE procède à la revalidation des NAS de tous les bénéficiaires établis avec succès dans le système du PCEE. Les bénéficiaires signalés par l’IAS sont identifiés dans le rapport de validation des NAS en utilisant les problèmes suivants :

  1. NAS est non utilisable;
  2. NAS est utilisable;
  3. NAS lié.

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. Rapports de surveillance liés à l’établissement d’un REEE

3 rapports de surveillance sont liés à des problèmes que les promoteurs rencontrent souvent lors de l’établissement d’un REEE :

  • le rapport de surveillance de contrats non enregistrés;
  • le rapport d’erreur de NAS;
  • le rapport de la règle de 3 ans.

Le système du PCEE informe les promoteurs individuels par courriel lorsque ces rapports en format Excel peuvent être téléchargés. Cela est fait par courriel et les rapports peuvent être récupérés par l’entremise du logiciel de GTFS.

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.1.1. Transaction 100‑01 traitée avec succès

Ce rapport en format Excel présente les contrats non enregistrés. Plus spécifiquement, ceux pour lesquels une transaction de renseignements sur le contrat (100‑01) a été traitée avec succès, mais dont les problèmes suivants demeurent :

  • la transaction 200‑03 est manquante ou a été rejetée;
  • la transaction 200‑04 est manquante ou a été rejetée;
  • les transactions 200‑03 et 200‑04 sont manquantes ou ont été rejetées.

Le rapport Excel présente les colonnes suivantes pour chaque identificateur de contrat non enregistré :

  • période de déclaration;
  • ID du régime type;
  • ID du contrat;
  • ID de la transaction du promoteur pour le TE 100;
  • date de la transaction pour le TE 100;
  • raison du non‑enregistrement.
3.4.3.1.2. Transaction 100‑01 manquante ou rejetée

Ce rapport Excel présente les contrats non enregistrés. Plus spécifiquement, ceux pour lesquels une transaction de renseignements sur le contrat (100‑01) a été rejetée ou n’a jamais été transmise. Le rapport Excel présente les colonnes suivantes pour chaque identificateur de contrat non enregistré :

  • ID du régime type;
  • ID du contrat;
  • raison du non‑enregistrement.

Si la transaction 100‑01 est manquante ou a été rejetée, le contrat ne sera pas inclus dans le rapport mensuel d’enregistrement du contrat (TE 950). Le numéro d’identification du régime type et le numéro d’identification du contrat fournis dans les rapports de surveillance de contrats non enregistrés correspondants sont obtenus à partir des transactions financières traitées avec succès qui se réfèrent au numéro d’identification du contrat.

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;
    • sexe.

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;
    • sexe.

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 apparait sur le rapport.

3.5. Traitement d’autres transactions de REEE

Tout d’abord, les renseignements sur le contrat, le souscripteur et le bénéficiaire doivent être établis avec exactitude dans le système du PCEE. Par la suite, toutes les autres transactions de promoteur pour ce bénéficiaire peuvent être traitées par le système du PCEE.

3.5.1. Traitement des transactions suivant un ordre logique

Le système du PCEE traite les transactions dans une séquence logique chaque mois. Donc, les enregistrements dans chaque fichier de promoteur peuvent être présentés dans n’importe quel ordre. Comme les transactions non financières sont traitées avant les transactions financières, les promoteurs peuvent soumettre les 2 types de transactions dans le même fichier. Cependant, les transactions financières ne peuvent être traitées qu’après que le bénéficiaire associé ait été établi avec succès dans le système du PCEE.

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.2. Champs utilisés pour chaque type de transaction de TE 400

Ce ne sont pas tous les champs qui sont utilisés pour chaque type de transaction de TE 400. Néanmoins, si un champ n’est pas utilisé, il doit contenir des caractères de remplissage. Cela est une exigence pour satisfaire aux spécifications prescrites par les NID pour le format du champ. L’Annexe D des NID présente les champs utilisés pour chaque type de transaction de TE 400.

3.5.3. Correction des transactions déjà traitées par le système du PCEE

Les promoteurs sont responsables de communiquer des renseignements exacts au système du PCEE. Si des renseignements inexacts ont été traités avec succès par le système du PCEE, le promoteur doit prendre les mesures appropriées pour corriger ces inexactitudes. Le processus requis dépend de la transaction qui doit être corrigée.

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. Il 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.

Tableau 7 : Indicateur d’annulation
Champ dans la nouvelle transaction Position Valeur de champ
Indicateur d’annulation 121 2 = Annulation
ID de la transaction originale du promoteur 122 à 136 Correspondance à la transaction à annuler
NE original du promoteur 137 à 151 Correspondance à la transaction à annuler

La transaction transmise pour annuler une autre transaction doit comprendre un nouvel identificateur (unique) de transaction du promoteur (position 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 erreur administrative (par exemple, le mauvais bénéficiaire). Dans ce cas, 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.3.4. Demandes pour la SEEAS (410‑31)

Parfois, le système du PCEE a traité avec succès une demande de SEEAS contenant une erreur administrative (par exemple, une date de transaction erronée). Dans ce cas, le promoteur doit soumettre une annulation de la demande de SEEAS (410‑31) au système du PCEE. Ceci annule la demande de SEEAS initiale et le promoteur peut alors soumettre une demande de SEEAS (410‑30) corrigée, si nécessaire.

L’annulation d’une transaction de cotisation (400‑11) associée à une demande de SEEAS annule automatiquement la demande de SEEAS.

3.5.4. Cotisations et demandes de SCEE (400‑11)

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.

Tableau 8 : Champs clés pour 400‑11
Champs clés pour 400‑11 Position Notes
NAS du bénéficiaire 78 à 86 Le NAS du bénéficiaire doit exister dans le système du PCEE. Pour plus de renseignements, se référer au code d’erreur 7001 dans l’Annexe E. Comprendre les codes d’erreurs.
Montant de la cotisation 87 à 95 Il ne faut pas que les promoteurs supposent que ce montant représente une « cotisation subventionnée ». Reportez‑vous au champ prévu pour le montant de la cotisation subventionnée (165 à 173) dans le TE 900.
Subvention demandée 96 Le système du PCEE ne versera pas la SCEE pour une cotisation à moins que ce champ ne soit « 1 » (Oui).
Responsable/conjoint 229 à 243 La SCEE supplémentaire ne sera pas versée pour une cotisation à moins que ces champs ne soient validés avec succès auprès de l’ARC. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions de SCEE supplémentaire. Pour plus de renseignements, se référer au code d’erreur 1014 dans l’Annexe E. Comprendre les codes d’erreurs.
Prénom du responsable/conjoint 244 à 263 La SCEE supplémentaire ne sera pas versée pour une cotisation à moins que ces champs ne soient validés avec succès auprès de l’ARC. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions de SCEE supplémentaire. Pour plus de renseignements, se référer au code d’erreur 1014 dans l’Annexe E. Comprendre les codes d’erreurs.
Nom du responsable/conjoint 264 à 283 La SCEE supplémentaire ne sera pas versée pour une cotisation à moins que ces champs ne soient validés avec succès auprès de l’ARC. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions de SCEE supplémentaire. Pour plus de renseignements, se référer au code d’erreur 1014 dans l’Annexe E. Comprendre les codes d’erreurs.
Type de responsable/conjoint 284 La SCEE supplémentaire ne sera pas versée pour une cotisation à moins que ces champs ne soient validés avec succès auprès de l’ARC. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions de SCEE supplémentaire. Pour plus de renseignements, se référer au code d’erreur 1014 dans l’Annexe E. Comprendre les codes d’erreurs.

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.

Tableau 9 : Champs clés de TE 900 pour la transaction 400‑11
Champs clés de TE 900 pour 400‑11 Position Notes
Montant de la subvention 26 à 36 Prévu pour le montant de la SCEE de base, versé pour la cotisation correspondante.
ID de la transaction du promoteur 52 à 66 Prévu pour la transaction de cotisation (400‑11) associée.
Raison de refus 67 Prévu pour la raison de refus si le montant total de la SCEE de base n’est pas versé.
Origine de la transaction 68 Pour plus de renseignements, se référer à la rubrique 3.5.4.3. Origines des transactions pour la SCEE
Montant de la SCEE supplémentaire 136 à 144 Indique le montant de la SCEE supplémentaire versé pour la cotisation correspondante.
Montant de la cotisation subventionnée 165 à 173 Indique le montant de la cotisation qui donne lieu à la SCEE.
Raison de refus de la SCEE supplémentaire 174 Fournis la raison de refus si le montant total de la SCEE supplémentaire n’est pas versé.

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.3.1.  0 – Initiée par le promoteur

Si le système du PCEE traite une transaction de cotisation (400‑11), le promoteur reçoit un TE 900 dans le rapport de traitement des transactions. Cela va confirmer le traitement avec succès de cette transaction. Le code d’origine de la transaction (position 68) indiquera que le TE 900 a été initié par le promoteur (origine de la transaction = 0).

3.5.4.3.2. D’autres origines des transactions

Il se peut aussi qu’un promoteur reçoive d’autres TE 900 concernant la SCEE dans le rapport de traitement des transactions. Ces rapports pourraient indiquer le besoin de mettre à jour le solde de la SCEE pour le REEE. Le tableau ci‑dessous présente la manière d’interpréter les divers codes d’origine de la transaction (position 68) pour ces autres enregistrements.

Tableau 10 : Interprétation des divers codes d’origine de la transaction
Code Explication
1 Réexamen : Par exemple, une demande de SCEE est refusée initialement en raison de la limite annuelle de la SCEE. Elle peut être accordée subséquemment par le versement de la SCEE correspondante lorsqu’un promoteur annule les autres transactions pour le même bénéficiaire.
2 Initiée par le PCEE : Un agent de soutien aux promoteurs du PCEE peut effectuer une intervention manuelle. Cela aura une incidence sur le solde du compte de la SCEE dans un REEE.
4 Réexamen par suite d’une réévaluation par l’ARC : L’admissibilité d’un bénéficiaire à la SCEE supplémentaire peut changer après une réévaluation par l’ARC. Cela pourrait changer le montant de la SCEE supplémentaire versé pour les cotisations.

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. Renseignements sur le responsable/conjoint (511‑12)

Dans les NID, le terme « responsable/conjoint » peut faire référence au :

  • responsable du bénéficiaire;
  • époux cohabitant du responsable; ou
  • conjoint de fait visé du responsable.

Lorsqu’une (400‑11) est traitée par le système du PCEE, le promoteur peut utiliser la transaction 511‑12 sur cette cotisation. Elle est utilisée pour fournir des renseignements nouveaux ou mis à jour sur le responsable/conjoint qui n’a pas donné lieu à la SCEE supplémentaire parce que :

  • aucun renseignement sur le responsable/conjoint n’a été fourni dans la transaction de cotisation initiale; ou
  • des renseignements inexacts sur le responsable/conjoint ont été fournis dans la transaction de cotisation initiale.

Les promoteurs doivent réussir le test de l’industrie pour les transactions 511‑12 avant de soumettre les transactions 511‑12 au système du PCEE.

Les promoteurs doivent soumettre une transaction 511‑12 distincte pour chaque transaction 400‑11 correspondante.

3.5.5.1. Champs clés pour 511‑12

Tableau 11 : Champs clés pour 511‑12
Champs clés pour 511‑12 Position Notes
Date de la transaction 4 à 11 Doit être la même que la date de la transaction 400‑11 ou une date après. Pour plus de renseignements, se référer aux codes d’erreurs 5032, 5033 et 7039 de l’Annexe E. Comprendre les codes d’erreurs.
Numéro du promoteur lié à la transaction relative à la cotisation 69 à 83 Identifie la transaction 400‑11 pour laquelle la SCEE supplémentaire est demandée. La transaction sera rejetée si la transaction 400‑11 correspondante n’est pas actuellement traitée ou n’a pas demandé la subvention. Pour plus de renseignements, se référer aux codes d’erreurs 5025, 5026, 5027 et 5030 dans l’Annexe E. Comprendre les codes d’erreurs.
NE du promoteur de la cotisation 84 à 98 NE du promoteur transmis lors de la transaction 400‑11 pour laquelle la SCEE supplémentaire est demandée.
Responsable/conjoint 99 à 113 Ces champs doivent être validés avec succès par l’ARC avant que le système du PCEE verse la SCEE supplémentaire pour la cotisation en question.
Prénom du responsable/conjoint 114 à 133 Ces champs doivent être validés avec succès par l’ARC avant que le système du PCEE verse la SCEE supplémentaire pour la cotisation en question.
Nom du responsable/conjoint 134 à 153 Ces champs doivent être validés avec succès par l’ARC avant que le système du PCEE verse la SCEE supplémentaire pour la cotisation en question.
Type de responsable/conjoint 154 Ces champs doivent être validés avec succès par l’ARC avant que le système du PCEE verse la SCEE supplémentaire pour la cotisation en question.

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.

Tableau 12 : Champs clés de TE 900 pour la transaction 511‑12
Champs clés de TE 900 pour 511‑12 Position Notes
ID de la transaction du promoteur 52 à 66 Prévu pour la transaction du responsable/conjoint associée.
Origine de la transaction 68 Raison pour laquelle un TE 900 a été généré dans le rapport de traitement des transactions.
Montant de la SCEE supplémentaire 136 à 144 Indique le montant de SCEE supplémentaire versé pour la cotisation associée.
Raison de refus de la SCEE supplémentaire 174 Fournit la raison de refus si le montant total de la SCEE supplémentaire n’est pas versé.

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.5.3.1. Problèmes courants pour 511‑12
  1. Règle de 3 ans :
    • une transaction 511‑12 est envoyée au système du PCEE. Elle est envoyée aux fins de traitement plus de 3 ans après la date de la transaction de cotisation (400‑11) correspondante. Par exemple :
      • 400‑11 : date de la transaction = 20100412;
      • 511‑12 : date de l’envoi du fichier = 20130704.
    • la transaction 511‑12 est rejetée, générant un code d’erreur 5033 dans un TE 800.

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

  2. La transaction 511‑12 précédent a la même date de transaction :
    • une transaction 511‑12 a été transmise pour une cotisation en particulier. Par contre, la SCEE supplémentaire a été refusée, générant une raison de refus dans le TE 900. Le promoteur a communiqué avec le souscripteur pour obtenir les bons renseignements sur le responsable/conjoint. Ensuite, il a transmis une autre transaction 511‑12 pour la même cotisation en indiquant la même date de transaction que la transaction précédente de 511‑12. La deuxième transaction 511‑12 est rejetée, générant un code d’erreur 5032 dans un TE 800.

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

    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, le système du PCEE aurait traité la demande de SCEE supplémentaire 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 aurait 2 options pour fournir les renseignements du responsable mis à jour. Le promoteur pourrait soumettre une transaction 511‑12 ou annuler et soumettre de nouveau la transaction 400‑11 originale avec les renseignements du particulier responsable mis à jour.

    À compter de 2018, l’époux ou le conjoint de fait cohabitant particulier responsable peuvent fournir ses renseignements pour demander la SCEE supplémentaire. Le promoteur de REEE peut soumettre ces renseignements du responsable/conjoint et ne pas recevoir une raison de refus « L » si ce renseignement correspond aux dossiers de l’ARC.

3.5.6. Demande de paiements de BEC (400‑24)

Seulement un REEE peut être actif à un moment donné pour de nouveaux versements du BEC au nom d’un bénéficiaire.

Pour demander le BEC, le souscripteur doit remplir et signer l’un des 2 formulaires de demande suivants :

  • si le bénéficiaire a moins de 18 ans, il doit utiliser le formulaire de demande EDSC SDE 0093;
  • lorsque le bénéficiaire est âgé de 18 à 20 ans, il doit utiliser le formulaire de demande EDSC SDE 0107.

Un fois que le souscripteur a rempli le formulaire approprié, le promoteur doit soumettre une seule transaction de demande de BEC (400‑24) au système du PCEE. Cette transaction permettra au bénéficiaire de recevoir les droits accumulés au BEC (le cas échéant). De plus, cette transaction rend le REEE actif pour les versements du BEC ultérieurs au nom de ce bénéficiaire.

Le système du PCEE verse automatiquement les versements du BEC pour chaque nouvelle année de prestation dans le REEE actif d’un bénéficiaire admissible. Aucune demande supplémentaire du BEC n’est nécessaire pour ce bénéficiaire.

Si un REEE qui a été résilié est actuellement actif pour recevoir des versements du BEC, les promoteurs devraient arrêter immédiatement tous les versements futurs du BEC dans le REEE pour ce bénéficiaire. Cela est possible en soumettant une transaction de demande de BEC (400‑24) avec le champ « subvention demandée » réglé à « 0 » (Non). Les promoteurs devraient envoyer des transactions uniques pour chaque bénéficiaire avec une demande active de BEC dans le REEE.

Un REEE peut également devenir inactif pour des versements futurs du BEC au nom d’un bénéficiaire en particulier selon l’une des situations suivantes :

  • le système du PCEE reçoit une transaction 400‑24 plus récente pour le bénéficiaire dans un autre REEE, dont la valeur du champ « subvention demandée » est « 1 » (Oui);
  • le système du PCEE reçoit une transaction de remboursement de subvention (400‑21) pour un bénéficiaire avec une raison de remboursement « 3 » (résiliation de contrat). Aussi, le montant du remboursement du BEC est supérieur à zéro et la date de la transaction est plus récente que la dernière demande de BEC pour ce REEE.

3.5.6.1. Champs clés pour 400‑24

Tableau 13 : Champs clés pour 400‑24
Champs clés pour 400‑24 Position Notes
NAS du bénéficiaire 78 à 86 Le NAS du bénéficiaire doit exister dans le système du PCEE. Pour plus de renseignements, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.
Subvention demandée 96 Prévu pour rendre le REEE actif ou inactif pour les versements du BEC de ce bénéficiaire.

Une valeur de « 1 » (Oui) le rend actif, tandis qu’une valeur de « 0 » (Non) le rend inactif.
Responsable/conjoint 229 à 243 Pour les bénéficiaires agés de moins de 18 ans, ce champ doit être validé avec succès auprès de l’ARC avant que le système du PCEE verse le BEC pour le bénéficiaire. Les renseignements sur le responsable/conjoint ne sont pas requis pour les bénéficiaires agés de 18 à 20 ans. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions du BEC. Pour plus de renseignements, se référer au code d’erreur 1012 dans l’Annexe E. Comprendre les codes d’erreurs.
Prénom du responsable/conjoint 244 à 263 Pour les bénéficiaires agés de moins de 18 ans, ce champ doit être validé avec succès auprès de l’ARC avant que le système du PCEE verse le BEC pour le bénéficiaire. Les renseignements sur le responsable/conjoint ne sont pas requis pour les bénéficiaires agés de 18 à 20 ans. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions du BEC. Pour plus de renseignements, se référer au code d’erreur 1012 dans l’Annexe E. Comprendre les codes d’erreurs.
Nom du responsable/conjoint 264 à 283 Pour les bénéficiaires agés de moins de 18 ans, ce champ doit être validé avec succès auprès de l’ARC avant que le système du PCEE verse le BEC pour le bénéficiaire. Les renseignements sur le responsable/conjoint ne sont pas requis pour les bénéficiaires agés de 18 à 20 ans. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions du BEC. Pour plus de renseignements, se référer au code d’erreur 1012 dans l’Annexe E. Comprendre les codes d’erreurs.
Type de responsable/conjoint 284 Pour les bénéficiaires agés de moins de 18 ans, ce champ doit être validé avec succès auprès de l’ARC avant que le système du PCEE verse le BEC pour le bénéficiaire. Les renseignements sur le responsable/conjoint ne sont pas requis pour les bénéficiaires agés de 18 à 20 ans. De plus, le promoteur doit avoir l’autorisation de soumettre des transactions du BEC. Pour plus de renseignements, se référer au code d’erreur 1012 dans l’Annexe E. Comprendre les codes d’erreurs.

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.

Tableau 14 : Champs clés de TE 900 pour les transactions 400‑24
Champs clés de TE 900 pour 400‑24 Position Notes
ID de la transaction du promoteur 52 à 66 Identifie la transaction de demande de BEC (400‑24) associée.
Raison de refus 67 Fournit la raison de refus si le montant total du BEC n’est pas versé.
Origine de la transaction 68 Pour plus de renseignements, se référer à la rubrique 3.5.6.3. Origines des transactions pour le BEC
Montant du BEC 127 à 135 Indique le montant du BEC versé.

3.5.6.3. Origines des transactions pour le BEC

3.5.6.3.1.  0 – Initiée par le promoteur

Le système du PCEE reçoit une demande de BEC. Le paiement du BEC sera effectué si, à ce moment‑là, le bénéficiaire a des droits accumulés au BEC. Le promoteur reçoit un TE 900 dans le rapport de traitement des transactions, reconnaissant le traitement réussi d’une demande de BEC. Le code d’origine de la transaction (position 68) indiquera que le TE 900 a été initié par le promoteur (origine de la transaction = 0).

3.5.6.3.2. D’autres origines des transactions

Un promoteur pourrait aussi recevoir un TE 900 dans le rapport de traitement des transactions pour d’autres raisons. Ceci pourrait indiquer que le solde du BEC devrait être mis à jour pour le bénéficiaire par le promoteur. Le tableau ci‑dessous présente la manière d’interpréter les divers codes d’origine de la transaction (position 68) pour ces autres enregistrements.

Tableau 15 : Interprétation des différents codes d’origine des transactions
Code Explication
1 Réexamen : Par exemple, le promoteur reçoit un refus pour une demande de BEC en raison de la limite annuelle. Elle peut être accordée subséquemment par le versement du BEC correspondant lorsqu’un promoteur annule les autres transactions pour le même bénéficiaire.
2 Initiée par le PCEE : Un agent de soutien aux promoteurs du PCEE peut effectuer une intervention manuelle. Cette dernière aura une incidence sur le solde du compte du BEC d’un bénéficiaire.
4 Réexamen par suite d’une réévaluation par l’ARC : L’admissibilité d’un bénéficiaire au BEC peut changer. Cela peut se produire lorsque l’ARC procède à une réévaluation du revenu modifié du particulier responsable d’un bénéficiaire.
6 Versement du BEC pour la nouvelle année de prestation : Les promoteurs transmettent une seule demande de BEC par bénéficiaire. Si un bénéficiaire est admissible au BEC lors d’une année subséquente, le système du PCEE versera automatiquement le montant du BEC pour cette année.
7 Versement du droit au BEC : Par exemple, les versements du BEC pour un bénéficiaire pourraient être remboursés à partir d’un REEE résilié. S’il y a un autre REEE actif pour le BEC du même bénéficiaire, le montant du BEC remboursé serait versé à ce REEE.
9 Demande de BEC inactive : Par exemple, un REEE actif à l’origine pour les versements du BEC d’un bénéficiaire. Il deviendrait inactif si un promoteur transmettait une demande de BEC plus récente pour le même bénéficiaire dans un autre REEE.

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 SDE0107) 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. SEEAS (410‑30 et 410‑31)

Il existe 2 types de transactions de la SEEAS. Le type de transaction 30 ou 31 spécifiée dans la transaction SEEAS (TE 410) :

  • 410‑30 = demande de SEEAS;
  • 410‑31 = annulation de la demande de SEEAS.

Ces 2 transactions font référence à une transaction de cotisation traitée (400‑11). Elles utilisent l’ID de transaction du promoteur et le NE du promoteur de la transaction de cotisation correspondante.

Demande de SEEAS : Le promoteur doit envoyer une transaction de demande de SEEAS distincte (410‑30) pour chaque transaction de cotisation (400‑11) afin d’attirer le paiement de la SEEAS pour cette cotisation.

Annulation de demande de SEEAS : Le promoteur doit utiliser la transaction d’annulation de demande de SEEAS (410‑31) uniquement pour corriger une erreur administrative (par exemple, une date de transaction erronée). Lorsqu’un promoteur annule une demande de SEEAS, le système du PCEE rétablit le montant annulé de la SEEAS au droit à la SEEAS du bénéficiaire.

La transaction annulation de demande de SEEAS (410‑31) annule la demande de SEEAS sur une transaction de cotisation spécifique (400‑11). Elle n’annule pas la transaction de cotisation originale. Cependant, l’annulation d’une transaction de cotisation associée à une demande de SEEAS annulera automatiquement la demande de SEEAS.

3.5.7.1. Champs clés des transactions TE 410

Voici les champs clés pour les transactions de la SEEAS (TE 410).

Tableau 16 : Champs clés de TE 410
Champs clés des transactions TE 410 Position Notes
Date de la transaction 4 à 11 Utilisé pour valider les raisons de refus de demandes de SEEAS :
  • O = Demande tardive de SEEAS
  • D = Transaction tardive
  • 9 = Autre
Type de transaction 42 à 43 Détermine le type de transaction relative à la SEEAS :
  • 30 = Demande de SEEAS
  • 31 = Annulation de la demande de SEEAS
Numéro du promoteur concernant la transaction relative à la cotisation 69 à 83 Identificateur de la transaction 400‑11 pour laquelle la SEEAS est demandée ou annulée.
NE du promoteur lié à la cotisation 84 à 98 NE du promoteur transmis lors de la transaction 400‑11 pour laquelle la SEEAS est demandée ou annulée.

Parmi les dates suivantes, les promoteurs doivent utiliser celle qui est la plus récente pour déterminer la date de la transaction d’une demande de SEEAS :

  • la date à laquelle le souscripteur remplit un formulaire de demande de SEEAS; ou
  • la date à laquelle le souscripteur fait la cotisation correspondante.

Par exemple, un souscripteur a commencé à cotiser à un REEE individuel le 14 octobre 2013. Il a rempli le formulaire de demande de SEEAS pour le bénéficiaire le 11 février 2014. La date de transaction de toutes les demandes de SEEAS pour des cotisations faites avant d’avoir rempli le formulaire de demande de SEEAS doit être le 11 février 2014. Toute demande de SEEAS pour des cotisations faites après cette date doit avoir la même date de transaction que celle de la transaction de cotisation.

3.5.7.2. Champs clés de TE 910 pour TE 410

Le système du PCEE reconnaîtra chaque transaction de demande de SEEAS (410‑30) traitée avec succès et chaque transaction d’annulation de demande de SEEAS (410‑31). Il le fait en envoyant aux promoteurs un TE 910 correspondant dans leur rapport mensuel de traitement des transactions.

Le système du PCEE pourrait générer un TE 910 dans le rapport de traitement des transactions en réponse à d’autres transactions. Cela se produirait si elles ont une incidence sur le solde du compte théorique de la SEEAS dans un REEE.

Par exemple, le système du PCEE peut envoyer un TE 900 et un TE 910 dans le rapport de traitement des transactions pour la même transaction financière (TE 400). Cela se produira selon l’une des situations suivantes :

  • le montant du PAE de la SEEAS ou le montant de la SEEAS est supérieur à 0; ou
  • la transaction de cotisation (400‑11) pour laquelle un montant de la SEEAS a été payé est annulée.

Voici les champs clés de TE 910 pour des transactions de la SEEAS.

Tableau 17 : Champs clés de TE 910 pour TE 410
Champs clés de TE 910 pour TE 410 Position Notes
Montant de la SEEAS 4 à 14 Montant du changement dans le solde du compte de la SEEAS en raison du traitement réussi de la transaction associée.
Raison de refus 45 Fournit la raison de refus si le montant total de la SEEAS n’est pas versé.
Origine de la transaction 46 Pour plus d’information, se référer à la rubrique 3.5.7.4. Origines des transactions pour la SEEAS
ID du contrat 72 à 86 Identifie le numéro d’identification du contrat pour lequel une intervention manuelle a été effectuée (initiée par le PCEE).
Date de la transaction du PCEE 87 à 94 Identifie la date à laquelle une intervention manuelle a été effectuée par un agent de soutien aux promoteurs du PCEE (initiée par le PCEE).
NAS 95 à 103 Identifie le NAS du bénéficiaire pour lequel une intervention manuelle a été effectuée (initiée par le PCEE).

3.5.7.3. Période de suspension de la SEEAS

Le 22 mars 2017, le gouvernement de la Saskatchewan a annoncé dans son budget provincial. Il a suspendu la SEEAS à compter du 1er janvier 2018, et ce, jusqu’à nouvel ordre. Les promoteurs peuvent décider de continuer d’accepter et de traiter les demandes de SEEAS après le 1er janvier 2018. Toutefois, aucune SEEAS ne sera versée pendant la période de suspension.

Des renseignements supplémentaires concernant la suspension de la SEEAS sont disponibles sur la page Web Canada.ca/ressourcesREEE dans les bulletins d’information suivants.

Tableau 18 : Bulletins d’information présentant des informations complémentaires relatives à la suspension de la SEEAS
Bulletins d’information Date
Avis #711 23 mars 2017
Avis #722 12 juin 2017
Avis #735 20 septembre 2017
Avis #740 8 novembre 2017

3.5.7.4. Origines des transactions pour la SEEAS

3.5.7.4.1.  0 – Initiée par le promoteur

Si la SEEAS est versée suite à une transaction 410‑30, le promoteur reçoit un TE 910 dans le rapport de traitement des transactions. Cela reconnaît le traitement réussi de cette demande. Le code d’origine de la transaction (position 46) indiquera que le TE 910 a été initié par le promoteur (origine de la transaction = 0).

3.5.7.4.2. D’autres origines des transactions

Un promoteur peut aussi recevoir d’autres enregistrements concernant la SEEAS dans le rapport de traitement des transactions. Certains de ces enregistrements pourraient indiquer le besoin de mettre à jour le solde de la SEEAS pour le REEE.

Le tableau ci‑dessous présente la manière d’interpréter les divers codes d’origine de la transaction (position 68) pour ces autres enregistrements.

Tableau 19 : Interprétation des différents codes d’origine des transactions
Code Explication
1 Réexamen : Par exemple, une demande de SEEAS refusée en raison de la limite annuelle de la SEEAS. Celle‑ci peut être accordée subséquemment par le versement du montant de la SEEAS correspondant lorsqu’un promoteur annule les autres transactions pour le même bénéficiaire.
2 Initiée par le PCEE : Un agent de soutien aux promoteurs du PCEE peut exécuter une intervention manuelle. Cela aura une incidence sur le solde du compte de la SEEAS dans le REEE.
A Annulation de la cotisation : Les promoteurs doivent mettre à jour les comptes théoriques. Lorsqu’ils annulent une cotisation pour laquelle un montant de la SEEAS a été versé, ils doivent mettre à jour le compte théorique de la SEEAS du REEE.
B Nouvelle demande de SEEAS : Si un promoteur transmet de multiples demandes de SEEAS pour une même cotisation, le système du PCEE versera la SEEAS à la demande de la plus récente traitée pour une cotisation en particulier. Le promoteur doit faire des ajustements au compte de la SEEAS pour que seul le dernier versement de la SEEAS s’ajoute au solde du compte de la SEEAS. Tout autre versement de la SEEAS pour la même cotisation doit être soustrait du solde du compte de la SEEAS.

3.5.7.5. Échéancier relatif à la SEEAS

3.5.7.5.1. Avant la période de suspension de la SEEAS
  1. Raison de refus O (demande de SEEAS en retard) : les souscripteurs avaient 3 ans pour présenter une demande de SEEAS après avoir effectué une cotisation admissible à un REEE. Le système du PCEE envoyait aux promoteurs une raison de refus « O » si :
    • la date de transaction de la demande de SEEAS était de plus de 3 ans après la date de transaction liée à la cotisation; et
    • que la demande était transmise au système du PCEE au plus tard 17 h, heure de l’Est, le 5 janvier 2018.
  2. Raison de refus D (transaction en retard) : les promoteurs avaient 3 ans pour traiter avec succès une demande de SEEAS. Ils devaient 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 SEEAS dans le fichier. Le système du PCEE envoyait aux promoteurs, une raison de refus « D » pour les demandes de SEEAS traitées après cette limite de 3 ans.
3.5.7.5.2. Pendant la période de suspension de la SEEAS
  1. Raison de refus 9 (autre) : les demandes de SEEAS soumises au système du PCEE recevront une raison de refus « 9 » (autre). Cela est applicable si la demande n’est pas liée à une cotisation pour laquelle une demande de SEEAS a été précédemment traitée avec succès;
  2. Code d’erreur 7001 (valeur invalide) : le système du PCEE rejettera les demandes de SEEAS liées à une cotisation pour laquelle une demande de SEEAS a été traitée précédemment avec succès. Les promoteurs recevront un code d’erreur 7001. Cela évitera que les montants admissibles à la SEEAS déjà reçus dans un REEE ne soient récupérés par EDSC.

3.5.7.6. Problèmes courants pour les transactions de la SEEAS

  1. Le bénéficiaire n’est pas établi dans le système :
    • le bénéficiaire au nom duquel une transaction de cotisation (400‑11) a été faite n’est pas encore établi avec succès dans le système du PCEE lors de la transmission d’une transaction de demande de SEEAS (410‑30) pour la cotisation. La transaction de cotisation est rejetée, générant un code d’erreur 7001 ou 7031 dans un TE 800 et la transaction de demande de SEEAS est rejetée, générant un code d’erreur 5026 dans un autre TE 800.

    Résolution : Pour plus de renseignements, se référer aux codes d’erreurs 7001, 7031 et 5026 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 SEEAS est demandée pour la cotisation au moyen d’une transaction 410‑30, 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 au code d’erreur 1010 dans l’Annexe E. Comprendre les codes d’erreurs.

  3. Suspension de la SEEAS :
    • un promoteur transmet une demande de SEEAS (410‑30) pendant la période de suspension de la SEEAS :
      • la demande de SEEAS est traitée, mais le versement de la SEEAS est refusé, générant une raison de refus « 9 » dans un TE 910;
      • les demandes de SEEAS liées à une cotisation pour laquelle une demande de SEEAS a été traitée précédemment avec succès seront rejetées. Elles recevront un code d’erreur 7001 dans un TE 800.
    • lorsqu’une demande de SEEAS est soumise, quelle que soit la date de la transaction, la transaction sera refusée ou rejetée pour la durée de la période de suspension.

    Résolution : Pour plus de renseignements, se référer à la raison de refus 9 dans l’Annexe F. Comprendre les raisons de refus et au code d’erreur 7001 dans l’Annexe E. Comprendre les codes d’erreurs. Durant la période de suspension, EDSC sera en mesure de traiter les interventions manuelles afin d’assurer la correction des erreurs administratives. Toutefois, elles se limiteront au montant de SEEAS déjà versé dans un REEE avant la suspension. Aucun nouveau versement de SEEAS ne sera fait pendant la période de suspension.

3.5.8. SEEEFCB (411‑40 et 411‑41)

Il existe 2 types de transactions relatives à la SEEEFCB. Le type de transaction 40 ou 41 spécifiée dans la transaction SEEEFCB (TE 411) :

  • 411‑40 = demande de SEEEFCB;
  • 411‑41 = annulation de la demande de SEEEFCB.

Demande de SEEEFCB : La transaction 411‑40 est utilisée pour demander la SEEEFCB pour un bénéficiaire donné. Le droit unique de 1 200 $ en SEEEFCB pour un bénéficiaire donné peut être versé dans un seul REEE. Il peut arriver que plusieurs demandes de SEEEFCB soient faites pour le même bénéficiaire dans des REEE différents. Si tel est le cas, le système du PCEE paiera le montant total de 1 200 $ de SEEEFCB à la première demande traitée avec succès (l’approche 1er arrivé, 1er servi). Les demandes subséquentes pour le même bénéficiaire recevraient la raison de refus E (le plafond cumulatif étant dépassé).

Annulation de la demande de SEEEFCB : La transaction 411‑41 annule les demandes de SEEEFCB déjà effectuées pour un bénéficiaire donné. Annuler une demande de SEEEFCB (411‑41) rétablira le droit du bénéficiaire au montant de 1 200 $ en SEEEFCB initial. Le promoteur doit utiliser la transaction 411‑41 pour corriger les erreurs administratives (par exemple, lorsqu’une demande de SEEEFCB est soumise pour le mauvais bénéficiaire).

Remboursement de la SEEEFCB : Lorsque la SEEEFCB est remboursée en utilisant une transaction de remboursement (400‑21), le droit à subvention d’un bénéficiaire n’est pas rétabli. Donc, les montants remboursés ne peuvent être versés de nouveau dans les REEE de bénéficiaire concerné.

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

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

Tableau 20 : Champs clés pour 411‑40 (demande de SEEEFCB)
Champs clés des transactions 411‑40 Position Notes
Date de la transaction 4 à 11 Utilisé pour la validation des raisons de refus :
  • 3 = Âge du bénéficiaire;
  • D = Transaction en retard.
Utilisé pour la validation du code d’erreur 7041.
NAS du bénéficiaire 69 à 77 Utilisé pour valider l’admissibilité à la 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.8.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.

Tableau 21 : Champs clés pour 411‑11 (annulation de la demande de SEEEFCB)
Champs clés des transactions 411‑41 Position Notes
ID de la transaction originale du promoteur 69 à 83 Identifie le numéro d’identification de la transaction du promoteur associé à la demande originale de SEEEFCB.
NE du promoteur original 84 à 98 Le NE du promoteur associé à la demande de SEEEFCB originale.

3.5.8.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.

Tableau 22 : Contraintes de temps pour la SEEEFCB
Date de naissance 1er jour pour présenter la demande Dernier jour pour présenter la demande
2006 Le 15 août 2016 Le 14 août 2019
2007 Le 15 août 2015 Le 14 août 2018
2008 Le 15 août 2015 Le 14 août 2018
2009 jusqu’au 14 août Le 15 août 2015 Le 14 août 2018
Le 15 août 2009 ou plus tard Le jour où le bénéficiaire a atteint l’âge de 6 ans Le jour avant que le bénéficiaire atteigne l’âge de 9 ans

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.8.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.

Tableau 23 : Champs clés de TE 911 pour TE 411
Champs clés de TE 911 pour TE 411 Position Notes
Montant de la SEEEFCB 4 à 14 Montant du solde du compte de la SEEEFCB qui a changé, en raison du traitement réussi d’une transaction.
ID de la transaction du promoteur 30 à 44 Indique la transaction associée.
Raison de refus 45 Fournit la raison de refus si la SEEEFCB n’a pas été versée.
Origine de la transaction 46
  • 0 – Initiée par le promoteur
  • 2 – Initiée par le PCEE
  • 5 – Liée au NAS
ID du contrat 72 à 86 Indique le numéro d’identification du contrat auquel une intervention manuelle a été effectuée (initiée par le PCEE).
Date de la transaction du PCEE 87 à 94 Indique la date à laquelle une intervention manuelle a été effectuée par un agent de soutien aux promoteurs du PCEE (initiée par le PCEE).
NAS 95 à 103 Indique le NAS d’un bénéficiaire auquel une intervention manuelle a été effectuée (initiée par le PCEE) (initiée par le PCEE).

3.5.8.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.8.3. Échéancier relatif à la SEEEFCB).

3.5.9. PAE (400‑13)

Les promoteurs utilisent les transactions 400‑13 pour rapporter le montant total de chaque paiement d’aide aux études (PAE). Ces transactions rapportent également les montants du PAE de chaque incitatif administré par EDSC. De plus elles fournissent des renseignements obligatoires supplémentaires à des fins de statistiques. Les promoteurs ne sont pas tenus de rapporter au système du PCEE des montants spécifiques de l’Incitatif québécois à l’épargne‑études (IQEE) dans les PAE. Toutefois, si un PAE comprend des montants d’IQEE, il faut inclure ces montants dans le montant total des PAE.

Les promoteurs doivent mettre à jour les comptes théoriques des REEE afin de refléter les montants d’incitatifs utilisés dans un PAE. Ils doivent aussi suivre les règlements pour calculer le montant de chaque incitatif à inclure dans les PAE. Pour plus de renseignements, se référer au Chapitre 10. Études postsecondaire et paiements d’aide aux études.

3.5.9.1. Champs clés des transactions 400‑13

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

Tableau 24 : Champs clés pour 400‑13
Champs clés des transactions 400‑13 Position Notes
NAS du bénéficiaire 78 à 86 Doit être établi dans le système du PCEE. Pour plus de renseignements, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.
Date de début de l’année scolaire 101 à 108 Prévu à des fins de statistiques.
Durée de l’année scolaire 109 à 111 Prévu à des fins de statistiques.
Montant du PAE attribuable à la subvention 161 à 169 Partie du PAE attribuable à la SCEE. Les montants de la SCEE de base et de la SCEE supplémentaire sont mis ensemble dans un compte théorique pour chaque REEE.
Montant total du PAE 170 à 178 La valeur doit être supérieure à zéro. Pour plus de renseignements, se référer au code d’erreur 3006 dans l’Annexe E. Comprendre les codes d’erreurs.
Durée du programme d’EPS 215 Prévu à des fins de statistiques.
Type d’études postsecondaires 216 à 217 Prévu à des fins de statistiques.
Code postal de l’établissement d’enseignement 218 à 227 Prévu à des fins de statistiques.
Année du programme d’EPS 228 Prévu à des fins de statistiques.
Montant du PAE attribuable au BEC 294 à 302 Partie du PAE attribuable au BEC.
Montant du PAE attribuable à la SEEAS 332 à 340 Partie du PAE attribuable à la SEEAS.
Montant du PAE attribuable à la SEEEFCB 350 à 358 Partie du PAE attribuable à la SEEEFCB.

3.5.9.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.

Tableau 25 : Champs clés de TE 900 pour 400‑13
Champs clés de TE 900 pour 400‑13 Position Notes
ID de la transaction du promoteur 52 à 66 Indique la transaction de PAE associée.
Montant de la subvention 26 à 36 Partie d’un PAE attribuable à la SCEE.
Montant du BEC 127 à 135 Partie d’un PAE attribuable au BEC.

3.5.9.3. Champs clés de TE 910 pour des PAE avec un montant de SEEAS

Si une transaction de PAE comprend un montant de SEEAS 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 910 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

Tableau 26 : Champs clés pour TE 910 pour des PAE avec un montant de la SEEAS
Champs clés de TE 910 pour des PAE avec un montant de SEEAS Position Notes
Montant de la SEEAS 4 à 14 Partie d’un PAE attribuable à la SEEAS.
ID de la transaction du promoteur 30 à 44 Indique la transaction de PAE associée.

3.5.9.4. 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.

Tableau 27 : Champs clés pour TE 911 pour des PAE avec un montant de la SEEEFCB
Champs clés de TE 911 pour des PAE avec un montant de SEEEFCB Position Notes
Montant de la SEEEFCB 4 à 14 Partie d’un PAE attribuable à la SEEEFCB.
ID de la transaction du promoteur 30 à 44 Indique la transaction de PAE associée.

3.5.9.5. 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.10. Retrait de cotisations pour EPS (400‑14)

Admissibilité : Les souscripteurs peuvent faire des retraits de cotisations (400‑14) pour les études postsecondaires (EPS) seulement si le bénéficiaire est admissible à un PAE. Un PAE n’a pas besoin d’être versé à l’égard d’un bénéficiaire pour qu’un souscripteur soit admissible à un retrait de cotisations d’EPS. Cependant, les promoteurs doivent recevoir la même preuve d’inscription nécessaire pour un PAE.

Ordre des retraits : Les cotisations sont considérées comme retirées des comptes théoriques dans l’ordre suivant :

  1. cotisations subventionnées;
  2. cotisations non subventionnées faites en 1998 ou après;
  3. cotisations non subventionnées faites avant 1998.

Aucune pénalité : Un retrait de cotisations pour EPS ne déclenche pas le remboursement d’incitatifs et n’a pas d’incidence sur l’admissibilité à la SCEE supplémentaire. Un retrait de cotisations dans d’autres situations déclenchera le remboursement d’incitatifs.

Répercussions fiscales et utilisation des fonds : Les souscripteurs peuvent retirer des cotisations en tout temps, sans répercussions fiscales. Les montants retirés ne sont pas inclus dans les T4A émis aux bénéficiaires recevant des PAE. Même s’ils ne sont pas obligés de le faire, les souscripteurs font normalement des retraits de cotisations pour EPS. Cela aidera à payer les études postsecondaires des bénéficiaires.

3.5.10.1. Champs clés des transactions 400‑14

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

Tableau 28 : Champs clés pour 400‑14
Champs clés des transactions 400‑14 Position Notes
NAS du bénéficiaire 78 à 86 Doit être établi dans le système du PCEE. Pour plus de renseignements, se référer aux codes d’erreurs 7001 et 7031 dans l’Annexe E. Comprendre les codes d’erreurs.
Date de début de l’année scolaire 101 à 108 Prévu à des fins de statistiques.
Durée de l’année scolaire 109 à 111 Prévu à des fins de statistiques.
Montant pour EPS 179 à 187 Montant de la cotisation retirée lorsqu’un bénéficiaire est admissible à un PAE.
Durée du programme d’EPS 215 Prévu à des fins de statistiques.
Type d’études postsecondaires 216 à 217 Prévu à des fins de statistiques.
Code postal de l’établissement d’enseignement 218 à 227 Prévu à des fins de statistiques.
Année du programme d’EPS 228 Prévu à des fins de statistiques.

3.5.10.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.

Tableau 29 : Champs clés de TE 900 pour 400‑14
Champs clés de TE 900 pour 400‑14 Position Notes
ID de la transaction du promoteur 52 à 66 Identifie la transaction associée au retrait de cotisations pour EPS.

3.5.10.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.11. Transferts de contrat (400‑19 et 400‑23)

Le transfert de fonds entre REEE a une incidence sur les soldes de comptes théoriques de chaque REEE. En tant que « livre des comptes » d’un REEE, les promoteurs ont la responsabilité de :

  • déclarer les montants exacts des incitatifs transférés; et
  • mettre à jour tous les comptes théoriques de manière convenable après un transfert.

À l’exception des montants du BEC qui sont propres aux bénéficiaires, tous les autres montants des comptes théoriques sont transférés à l’échelle du régime.

Chaque transfert de REEE doit être rapporté au système du PCEE dans 2 transactions :

  • transfert « sortie » (400‑23) du REEE cédant;
  • transfert « entrée » (400‑19) au REEE cessionnaire.

Les promoteurs rapportent uniquement au système du PCEE les montants transférés des incitatifs administrés par EDSC.

3.5.11.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.11.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.11.3. Champs clés pour les transactions de transfert

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

Tableau 30 : Champs clés pour les transactions de transferts
Champs clés pour les transactions de transfert Position Notes
Type de transaction 42 à 43
  • 19 = transfert « entrée »
  • 23 = transfert « sortie »
Montant de la subvention 152 à 160 Le montant total de la SCEE transféré (comprend les montants de la SCEE de base et de la SCEE supplémentaire)
ID de l’autre régime type 188 à 197
  • Les transferts de sortie (400‑23) désignent le numéro d’identification du régime type cessionnaire. Les transferts d’entrée (400‑19) désignent le numéro d’identification du régime type cédant.
  • Il doit s’agir du numéro d’identification du régime type valide dans le système du PCEE. Pour plus de renseignements, se référer au code d’erreur 1005 dans l’Annexe E. Comprendre les codes d’erreurs.
ID de l’autre contrat 198 à 212 Les transferts de sortie (400‑23) désignent le numéro d’identification du contrat cessionnaire. Les transferts d’entrée (400‑19) désignent le numéro d’identification du contrat cédant. Même si ce champ est obligatoire pour les transferts, il n’est pas validé par le système du PCEE.
Montant du BEC 285 à 293 Montant total du BEC transféré. Le montant de BEC déclaré lors d’une transaction de transfert est le montant global de BEC transféré pour tous les bénéficiaires d’un REEE.
Montant de la SEEAS 323 à 331 Montant total de la SEEAS transféré.
Montant de la SEEEFCB 341 à 349 Montant total de la SEEEFCB transféré.

3.5.11.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.

Tableau 31 : Champs clés de TE 900 pour les transactions de transfert
Champs clés de TE 900 pour les transactions de transfert Position Notes
ID de la transaction du promoteur 52 à 66 Indique la transaction de transfert (400‑19 ou 400‑23) associée.
Montant de la subvention 26 à 36 Le montant total de la SCEE transféré (comprend les montants de la SCEE de base et de la SCEE supplémentaire).
Montant du BEC 127 à 135 Montant total du BEC transféré.

3.5.11.5. Champs clés de TE 910 pour un transfert de SEEAS

Si une transaction de transfert comprend un montant de la SEEAS 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 910 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

Tableau 32 : Champs clés de TE 910 pour un transfert de SEEAS
Champs clés de TE 910 pour un transfert de SEEAS Position Notes
Montant de la SEEAS 4 à 14 Montant total de la SEEAS transféré.
ID de la transaction du promoteur 30 à 44 Indique la transaction de transfert (400‑19 ou 400‑23) associée.

3.5.11.6. 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.

Tableau 33 : Champs clés de TE 911 pour un transfert de SEEEFCB
Champs clés de TE 911 pour un transfert de SEEEFCB Position Notes
Montant de la SEEEFCB 4 à 14 Montant total de la SEEEFCB transféré.
ID de la transaction du promoteur 30 à 44 Indique la transaction de transfert (400‑19 ou 400‑23) associée.

3.5.11.7. 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.12. Remboursement d’incitatifs (400‑21)

Les politiques et règlements fédéraux et provinciaux précisent les situations dans lesquelles le remboursement des montants d’incitatifs d’un REEE est requis. Si tel est le cas, les promoteurs, ils doivent soumettre au système du PCEE des transactions de remboursement d’incitatifs (400‑21) comprenant les renseignements suivants :

  • le montant de chaque incitatif à rembourser;
  • la raison du remboursement.

Chacun des promoteurs reçoit un dépôt direct d’EDSC pour le versement de toutes les demandes d’incitatifs générant des versements mensuels. Le système du PCEE déduit le montant du dépôt direct à chacun par le total de tous les montants de remboursement transmit dans leurs transactions 400‑21 ce mois‑là.

3.5.12.1. Impact des remboursements sur les paiements futurs

Droit à la SCEE et à la SEEAS : Le droit d’un bénéficiaire à la SCEE ou à la SEEAS 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 et de la SEEAS 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 et de la SEEAS.

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.12.2. Champs clés de 400‑21

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

Tableau 34 : Champs clés de 400‑21
Champs clés pour 400‑21 Position Notes
NAS du bénéficiaire 78 à 86 Obligatoire seulement si le montant du BEC est supérieur à 0.
Montant de la subvention 152 à 162 Montant de la SCEE à rembourser.
Raison du remboursement 213 à 214 Raison du remboursement.

Pour plus de renseignements, se référer à la rubrique 3.5.12.3. Raisons du remboursement.
Montant du BEC 285 à 293 Montant du BEC à rembourser.
Montant de la SEEAS 323 à 331 Montant de la SEEAS à rembourser.
Montant de la SEEEFCB 341 à 349 Montant de la SEEEFCB à rembourser.

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.12.3. Raisons du remboursement

Tableau 35 : Raisons du remboursement
Code – Description Exemples
01 – Retrait de cotisation Des cotisations sont retirées alors qu’aucun bénéficiaire du REEE n’est admissible à un PAE. Le promoteur doit calculer le montant de la SCEE et de la SEEAS à rembourser suite à ce retrait.
02 – PRA Remboursement de tous les incitatifs lorsqu’un souscripteur reçoit un paiement de revenu accumulé (PRA) du REEE.
03 – Résiliation du contrat Remboursement de tous les incitatifs (le cas échéant) et notification au système du PCEE de la résiliation d’un REEE. La transaction est obligatoire à la résiliation d’un REEE.
04 – Transfert non admissible Remboursement de tous les incitatifs lors d’un transfert non admissible.
05 – Remplacement d’un bénéficiaire non admissible Remboursement de tous les incitatifs lors d’un remplacement non admissible de bénéficiaire.
06 – Paiement versé à un établissement d’enseignement Le souscripteur verse un revenu accumulé à un établissement d’enseignement agréé canadien plutôt que d’accepter un paiement de revenu accumulé. Le promoteur doit donc remboursement de tous les incitatifs.
07 – Révocation Remboursement de tous les incitatifs lors de la révocation par l’ARC de l’enregistrement d’un REEE.
08 – Ne satisfait plus à la condition de frère ou sœur seulement Un souscripteur ajoute un cousin à un REEE familial pour « frère ou sœur seulement ». Le promoteur doit rembourser les incitatifs qui peuvent être versés uniquement à un REEE pour « frère ou sœur seulement ».
09 – Décès Remboursement des incitatifs au décès d’un bénéficiaire. À l’exception du BEC, les incitatifs versés au nom d’un bénéficiaire décédé pourraient être utilisés par d’autres bénéficiaires du même REEE. Ils peuvent aussi être transférés à un autre REEE.
10 – Retrait de cotisations excédentaires Remboursement des montants de la SCEE et de la SEEAS si les cotisations ont été retirées pour corriger une cotisation excédentaire. Si le montant de la cotisation excédentaire ne dépasse pas 4 000 $ au moment du retrait, les montants de la SCEE et de la SEEAS à rembourser sont à 0. Toutefois, il faut toujours soumettre une transaction de remboursement (400‑21) au PCEE.
11 – Autre Les agents de soutien aux promoteurs pourraient suggérer l’utilisation de cette raison aux promoteurs dans des situations diverses.
12 – Non résident Remboursements des montants d’incitatifs s’il est déterminé que le bénéficiaire ne satisfait pas aux critères de résidence pour être admissible au versement d’incitatifs.

3.5.12.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.12.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 :

Tableau 36 : Champs clés de TE 900 pour 400‑21
Champs clés de TE 900 pour 400‑21 Position Notes
ID de la transaction du promoteur 52 à 66 Identifie la transaction de remboursement (400‑21) associée.
Montant de la subvention 26 à 36 Le montant total de la SCEE remboursé (comprenant possiblement des montants de la SCEE supplémentaire).
Montant du BEC 127 à 135 Montant total du BEC remboursé.

3.5.12.6. Champs clés de TE 910 pour un remboursement de SEEAS

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

Tableau 37 : Champs clés de TE 910 pour un remboursement de SEEAS
Champs clés de TE 910 pour un remboursement de SEEAS Position Notes
Montant de la SEEAS 4 à 14 Montant total de la SEEAS remboursé.
ID de la transaction du promoteur 30 à 44 Identifie la transaction de remboursement (TE 400‑21) associée.

3.5.12.7. 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.

Tableau 38 : Champs clés de TE 911 pour un remboursement de SEEEFCB
Champs clés de TE 911 pour un remboursement de SEEEFCB Position Notes
Montant de la SEEEFCB 4 à 14 Montant total de la SEEEFCB remboursé.
ID de la transaction du promoteur 30 à 44 Indique la transaction de remboursement (400‑21) associée.

3.5.12.8. 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 »). Il souhaite retirer les cotisations non subventionnées (les cotisations qui n’ont pas donné lieu à la subvention). Il 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, il 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.13. Rajustements au moment de la résiliation (400‑22)

Les promoteurs doivent utiliser une transaction de rajustement au moment de la résiliation (400‑22) dans un cas spécifique. Cette transaction doit être réservée à signaler au système du PCEE le montant des incitatifs qui ne peut être remboursé lors de la résiliation d’un REEE, en raison de pertes sur les placements.

Exemple – Lorsque les fonds du REEE sont insuffisants et que le régime est résilié

Au départ, la juste valeur marchande d’un REEE était de 3 000 $. Plus précisément, 2 500 $ en cotisations et 500 $ en SCEE. Le souscripteur décide de résilier le REEE après une perte considérable alors que la juste valeur marchande était de seulement 400 $. Le promoteur doit rembourser (400‑21) un montant de la SCEE. Le montant sera celui qui représente le moins élevé entre le résultat de la formule de calcul du remboursement des incitatifs fédéraux à l’épargne‑études et le solde du compte de la SCEE (400 $ dans cet exemple).

  • Valeur marchande du REEE : 400 $;
  • Revenus : 0 $;
  • Cotisations : 2 500 $;
  • Incitatifs provinciaux : 0 $;
  • SCEE : 500 $.

Les promoteurs doivent utiliser une formule pour rembourser les incitatifs fédéraux à l’épargne‑études dans les cas où la juste valeur marchande est inférieure au total du solde de la SCEE et du BEC.

La liste des événements qui déclenchent les remboursements lorsqu’il y a une perte considérable de placement dans un REEE est décrite dans l’article (11), paragraphe (3) du Règlement canadien sur l’épargne‑études.

Formule de calcul du remboursement des incitatifs fédéraux à l’épargne‑études dans les cas où la juste valeur marchande est inférieure au total du solde de la SCEE et du BEC.

(C × Y) / (Y + G) = montant des incitatifs fédéraux (SCEE, BEC) à rembourser :

  • C représente la juste valeur marchande des biens détenus dans le REEE, déterminée immédiatement avant l’événement en cause;
  • Y représente le solde total du compte de la subvention et de tous les comptes du BEC au titre du REEE immédiatement avant l’événement en cause; et
  • G représente le solde total des montants qui ont été versés dans le REEE dans le cadre d’un programme provincial désigné immédiatement avant l’événement en cause.

Calcul : Le remboursement de la SCEE à EDSC

(400 $ × 500 $) / (500 $ + 0 $) = 400 $

Remarque : s’il y a plus d’un incitatif fédéral ou incitatif provincial restant dans le REEE, le promoteur devra déterminer la proportion de chacun des incitatifs remboursable.

Pour équilibrer le montant de SCEE imputable de 500 $, le promoteur doit également soumettre au système du PCEE une perte de 100 $ de SCEE. Ils vont le faire en soumettant une transaction de rajustement au moment de la résiliation (400‑22).

3.5.13.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).

Tableau 39 : Champs clés pour 400‑22
Champs clés pour 400‑22 Position Notes
Montant de la subvention 152 à 162 Montant du rajustement pour la SCEE.
Montant du BEC 285 à 293 Montant du rajustement pour le BEC.
Montant de la SEEAS 323 à 331 Montant du rajustement pour la SEEAS.
Montant de la SEEEFCB 341 à 349 Montant du rajustement pour la SEEEFCB.

3.5.13.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.

Tableau 40 : Champs clés de TE 900 pour 400‑22
Champs clés de TE 900 pour 400‑22 Position Notes
ID de la transaction du promoteur 52 à 66 Indique la transaction de rajustement de la résiliation (400‑22) associée.
Montant de la subvention 26 à 36 Montant perdu de la SCEE.
Montant du BEC 127 à 135 Montant perdu du BEC.

3.5.13.3. Champs clés de TE 910 pour un rajustement au moment de la résiliation de la SEEAS

Si une transaction de rajustement au moment de la résiliation comprend un montant de la SEEAS 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 910 correspondant dans leur rapport mensuel de traitement des transactions. Les champs clés de ces enregistrements sont les suivants.

Tableau 41 : Portion des rajustements au moment de la résiliation attribuable à la SEEAS
Champs clés de TE 910 pour un rajustement de la SEEAS Position Notes
Montant de la SEEAS 4 à 14 Montant perdu de la SEEAS.
ID de la transaction du promoteur 30 à 44 Indique la transaction de rajustement de la résiliation (400‑22) associée.

3.5.13.4. 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.

Tableau 42 : Portion des rajustements au moment de la résiliation attribuable à la SEEEFCB
Champs clés de TE 911 pour un rajustement de la SEEEFCB Position Notes
Montant de la SEEEFCB 4 à 14 Montant perdu de la SEEEFCB.
ID de la transaction du promoteur 30 à 44 Indique la transaction de rajustement de la résiliation (TE 400‑22) associée.

3.5.13.5. 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 $;
  • SEEAS : 500 $.

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

Détails de la page

Date de modification :