DB2P - Déclarer
FR NL

DÉCLARER

  1. Vous pouvez effectuer les déclarations au moyen d’une application en ligne (portail de la sécurité sociale) ou les envoyer par batch (messages XML structurés). Il est également possible de combiner l’utilisation des deux canaux.

  2. Déclarations par batch

    La transmission de fichiers par batch, vous permet de transmettre simultanément une grand nombre de déclarations sous forme de messages structurés. Si vous souhaitez transmettre vos déclarations DB2P par batch vous devez créer un utilisateur technique, demander un certificat de sécurité  et choisir un canal batch. La demande dun certificat de sécurité prend environ 3 semaines.

    Lors de votre enregistrement dans le système de gestion des accès  (User management) de la sécurité social, un Gestionnaire local a été désigné pour votre organisme de pension pour la qualité "Gestionnaire pensions complémentaires". 

    Ce Gestionnaire local peut créer l’utilisateur technique. Cet utilisateur technique est la personne de contact au niveau de la qualité pour l’échange des données par batch. Un seul utilisateur technique peut donc être désigné pour toutes les applications au sein de cette qualité. Il doit avoir une connaissance technique de la manière dont l’échange des fichiers se produit.

    Lors de la création de cet utilisateur technique,le Gestionnaire local doit également choisir un canal batch. Il existe plusieurs canaux physiques pour échanger, par batch, des données par le réseau de la sécurité sociale. Si vous disposez déjà d'une connexion physique (ex. Isabel ou FTP) vous pouvez également l’utiliser pour les déclarations DB2P tant que ces canaux sont encore supportés. En général, il est recommandé d’utiliser le SFTP dont le coût est moins élevé pour une meilleure sécurité.

    Vous trouverez plus d’information sur les canaux physiques de communication avec le réseau de la sécurité sociale dans les documents suivants :

     

    - Pour la connexion via FTP

    - Pour la connexion via SFTP

    1. Introduire et transmettre les fichiers

       

      Les déclarations batch doivent être transmises à l’intégrateur de la sécurité sociale (Smals). Outre l’enregistrement dans le User Management, chaque entité déclarante doit aussi disposer d’une connexion physique. Pour les déclarations batch, il existe différentes solutions. Pour plus d’information à ce sujet vous pouvez consulter la rubrique Obtenir un accès sécurisé aux applications DB2P dans le menu "Avant de déclarer".

      Les fichiers de déclaration pour la simulation doivent être placés dans le folder INTEST pour une déclaration en simulation et IN pour une déclaration en production. Les fichiers de déclaration sont transmis avec un fichier de signature et un fichier vide. Trois fichiers doivent toujours être placés dans ce folder. Les noms de fichier adoptent la structure suivante:

      FI.DB2P.123456.20110701.00001.T.1.1

      FS.DB2P.123456.20110701.00001.T.1.1

      GO.DB2P.123456.20110701.00001.T.1

      Première partie du nom:
      FI: fichier de déclaration
      FS: fichier de signature
      GO: fichier vide qui initie le traitement

      Deuxième partie du nom:
      DB2P: traduit le contenu du fichier; DB2P indique qu’il s’agit d’un fichier de déclaration pour DB2P

      Troisième partie du nom:
      123456: il s’agit du numéro émetteur attribué à l’entité qui introduit la déclaration.
      Le numéro d’expéditeur est attribué lors de la création de l’utilisateur technique. Le gestionnaire local peut retrouver ce numéro via l'application "Gestion des Accès" sur le site portail de la sécurité sociale en cliquant sur le lien "Information" du menu "Echange via messages structurés".

      Quatrième partie du nom:
      20110701: il s’agit de la date de création du fichier sous la forme AAAAMMJJ

      Cinquième partie du nom:
      00001: il s’agit d’un numéro que vous pouvez choisir librement et qui indique le nom du fichier, de manière unique, par date de création et par environnement

      Sixième partie du nom:
      indique l’environnement de travail

      «R» est utilisé pour la production
      «T» est utilisé pour la simulation

      Septième partie du nom:
      1: indique le nombre de parties du fichier. Une déclaration peut au maximum comprendre 9 parties

      Huitième partie du nom:
      1: indique le numéro de la partie. Dès que le fichier GO vide est en place, tous les fichiers liés sont automatiquement traités.

      1. Xsd

        Les instances qui désirent déclarer par batch doivent créer les fichiers de déclaration au format XML. Ces messages XML doivent respecter un certain nombre d’exigences, stipulées dans un schéma XSD. 

        1. Régimes pour travailleurs salariés (LPC)
          Pour les déclarations dans le domaine LPC le schéma XSD 03.09.00 est actuellement d'application (cf. table des releases). En ouvrant ce fichier, vous aurez accès au toplevel XSD: db2p_v3.9.0_ externe \ db2p_v3.9.0 \ Déclaration \ db2p_v3.xsd.
           
          Pour la création d'un DVD pour transmettre des documents pdf (dans le cadre de la déclaration CreateRegulation) vous pouvez utiliser ce schéma XSD
        2. Autres régimes pour travailleurs salariés ( Autres LPC)
          Pour les déclarations dans le domaine LAutres PC le schéma XSD 01.04.00 est actuellement d'application (cf. table des releases). En ouvrant ce fichier, vous aurez accès au toplevel XSD: db2p-awap-v1.4.0_extern\db2p-awap-v1.4.0\Declaration\awap\db2pDeclarationsAWAP_v1.xsd
           
           
      2. Restrictions techniques

        Lors de l’échange de fichiers batch via les canaux de communication sécurisés, vous devez tenir compte de plusieurs restrictions techniques.

        Vous devez transmettre les fichiers à Smals sous forme non comprimée.

        Si la taille du fichier est supérieure à 200MB (ou à 50MB si les fichiers sont échangés via Isabel), vous devez transmettre le fichier en plusieurs parties. La taille de chacune des parties ne peut pas être supérieure à 200MB (ou à 50MB pour Isabel), vous pouvez transmettre au maximum 9 parties et la taille comprimée de toutes les parties ensemble ne peut pas être supérieure à 99 MB.

        La division du fichier en plusieurs parties se fait à un niveau technique. Lorsque le fichier est divisé, les parties individuelles ne satisfont pas isolément au XSD de déclaration, mais une fois le fichier assemblé par l’intégrateur, il doit satisfaire au schéma XSD.

        Les fichiers réponse sont transmis sous forme comprimée par l’intégrateur aux organismes de pension et de solidarité ou au fournisseur de services. Leur taille n’est pas supérieure à 50MB. Ces fichiers réponse sont des fichiers réponse fonctionnels qui satisfont chacun au XSD. Concrètement, cela signifie que sur un seul fichier d’input fonctionnel (qui doit éventuellement être scindé par l’entité participante en fonction des restrictions techniques), plusieurs fichiers réponse fonctionnels peuvent être transmis, sous format zip, et chacun d’une taille inférieure ou égale à 50MB.

  3. Déclarations via l’application en ligne

    Les applications en ligne DB2P permettent d’introduire des déclarations d’une manière simple et interactive depuis votre ordinateur.

    Pour introduire une déclaration dans l’application DB2P en ligne, une connexion internet suffit. Cette application est disponible sur le portail de la sécurité sociale ( www.socialsecurity.be, cliquez sur «Fonctionnaires et autres professionnels » et ensuite sur « Acteurs des pensions légales et complémentaires »). Ce manuel Accéder à l’application sur le site portail de la sécurité sociale vous guide écran après écran pour y accéder. 

    Sur la page d'accueil de l'application vous avez le choix de vous connecter en simulation ou en production. Les rôles suivants sont disponibles:

    • Déclaration : L’utilisateur reçoit accès à l’application en ligne DB2P en tant qu’utilisateur ordinaire. L’utilisateur peut créer des déclarations, de les corriger, de les annuler et de les consulter (à l’exception de SetDelegation, SetUserGroup et SetAuthorization).

    • Gestion des mandats et des droits d’accès : L’utilisateur reçoit accès à l’application en ligne DB2P en tant que Gestionnaire DB2P. L’utilisateur peut gérer les mandats entre entités et les droits d’utilisateur au sein de l’entité

    Remarque : Par défaut, les utilisateurs dans le cadre de DB2P peuvent poser tous les actes possibles pour l’entité qui les désigne. Un utilisateur désigné par une entité peut ainsi introduire toutes les déclarations initiales auxquelles l’entité est soumise ou pour lesquelles elle est mandatée ainsi que les corrections et annulations. L’utilisateur peut également consulter les déclarations auxquelles l’entité a accès.

    1. Manuels

      Les manuels suivants vous guident écran par écran dans les déclarations DB2P via l’application en ligne

  4. Chargement des PDF

    Pour chaque régime enregistré dans DB2P, vous devez communiquer tous les documents nécessaires à une vue complète des droits et obligations des parties concernées  (p.ex règlement de pension). Vous devez transmettre ces documents à Sigedis au format PDF, ceux-ci doivent satisfaire à une certain nombre d’exigences (cf. instructions version 01.08 section 4.3.1.13).

    Pour les nouveaux régimes que vous déclarez à partir de 2013, vous transmettez ces documents directement lors de la déclaration du régime (CreateRegulation).

    Pour les régimes introduits avant 2013, la règle est assouplie. Les documents ne doivent pas être présents dès la déclaration CreateRegulation, mais peuvent encore être chargés par la suite.

    Les documents PDF manquants doivent cependant être transmis au plus tard pour le 31 décembre 2012. Vous trouverez ici une vue d’ensemble des obligations et délais pour le chargement de ces documents PDF.

    Les déclarants qui, à cette date, n’ont pas chargé les documents nécessaires pour les régimes antérieurs à 2013 ne sont pas en ordre avec leurs obligations de déclaration. Les déclarations tardives seront bien entendu encore traitées, mais, à partir du 1er janvier 2013, un régime sans documents sera considéré comme enfreignant les instructions.

    Trois options s’offrent à vous pour transmettre les documents PDF des régimes antérieurs à 2013 :

    1. Via DVD

      La première option vous permet de transmettre simultanément sur DVD les documents afférents à plusieurs régimes (cf. chargement en masse). 

       

      Le téléchargement via DVD est uniquement disponible pour les documents en PDF des régimes LPC. Les documents en PDF des régimes Autres LPC doivent toujours être téléchargés via batch ou en ligne (cf. points 1 et 2).


      Dans ce cas, vous créez par régime un fichier dans lequel vous placez les documents qui y sont liés. Le nom du fichier doit correspondre à la référence du régime (SigedisId ou RegistrantId).

      Pour chaque régime pour lequel vous créez un fichier avec des documents PDF validés, le traitement aura pour effet une correction de la déclaration initiale CreateRegulation. Les données sur le DVD sont donc traitées comme s’il s’agissait d’une correction d’une déclaration introduite antérieurement. Attention, exceptionnellement, lors de cette correction les documents sont ajoutés aux documents éventuellement déjà existents du régime. Vous ne devez donc pas placer tous les documents du régime dans le dossier. Vous pouvez consulter les corrections au moyen de l’application en ligne sous “Gestion des déclarations”.

       

      Ce document détaille la procédure pour la création et l'envoi du DVD à Sigedis. Vous trouverez ici le schéma xsd ainsi que la liste des anomalies relatifs à la création des DVD.

      Outre le chargement en masse au moyen de DVD, vous pouvez également charger les PDF via les canaux de communications “habituels” utilisés pour l’introduction des déclarations DB2P : la déclaration par batch (cf. point 2) ou en ligne (cf. point 3).

    2. Via une déclaration batch

      Vous pouvez transmettre les documents PDF par régime via un message XML structuré. Pour ce faire, vous devez introduire une correction de la déclaration CreateRegulation originale qui a enregistré initialement le régime concerné dans DB2P (cf. instructions, section 4.4.4). Au moyen de la correction, vous communiquez que le document fait partie (rétroactivement) de la déclaration initiale. En d’autres termes, le document est rajouté à la déclaration CreateRegulation d’origine. 

      Vous pouvez aussi charger des documents PDF via une déclaration UpdateRegulation. Toutefois, vous ne pouvez utiliser une mise à jour que pour transmettre des documents relatifs à une évolution ou à une modification du régime dans le temps. Les documents dans une déclaration UpdateRegulation ne sont valables qu’à partir de la date d’entrée en vigueur de la modification du régime (cf. l’ApplicationDateChange). Cette date est différente de la date d’entrée en vigueur du régime lui-même (cf. ApplicationDate dans la déclaration CreateRegulation). Cela signifie que vous ne pouvez pas compléter le dossier d’origine du régime via une mise à jour ; la déclaration CreateRegulation initiale ne peut être complétée par ce moyen. Si vous transmettez quand même les documents exigés de régimes antérieurs à 2013 via une déclaration UpdateRegulation, le dossier sera incomplet pour le régime concerné.

    3. Via une déclaration en ligne

      Enfin, vous pouvez également charger les documents PDF nécessaires par régime en ligne. Ici aussi, vous ne pouvez compléter le dossier d’origine du régime qu’au moyen d’une correction et non via une mise à jour (voir point 2). Pour ce faire, choisissez le menu “Gestion des déclarations” de l’application en ligne DB2P et recherchez la déclaration initiale CreateRegulation du régime auquel le document doit être rajouté. Continuez via ‘Aperçu’ vers  ‘Corriger une déclaration’. Via l’écran ‘Données spécifiques” vous pouvez sélectionner et charger les documents PDF exigés dans le bloc ‘RegulationDocuments’.

       

  5. Environnements de production et de simulation
    1. Information générale

      En plus de l’environnement de production, Sigedis met à votre disposition, de façon permanente, un environnement de simulation dans lequel vous pouvez tester tant les déclarations par batch que les déclarations introduites via l’application portail.

      L’environnement de simulation est totalement distinct (end-to-end) de l’environnement de production de DB2P

       

       

    2. Versions disponibles

      La version 1.19 de l'application DB2P pour la déclaration des régimes pour travailleurs salariés (LPC/Autres LPC) est disponible en simulation et en production. Cette release note correspondante vous fournit plus d’information quant aux fonctionnalités disponibles dans cette version. 

       

       

    3. Simulation

      La simulation d’une déclaration vous permet de préparer et de tester votre déclaration avant son envoi dans l’environnement de production. L’usage de l’environnement de simulation permet donc, d'une part, de tester à l’avance si l’échange technique des fichiers de données se déroule correctement et, d’autre part, de limiter le nombre d’anomalies en vue de la déclaration en production.

      Une déclaration en simulation qui aboutit ne sera jamais considérée comme une déclaration en production. Cela signifie que les déclarations effectuées et traitées dans l’environnement de simulation n’ont aucune valeur officielle. La seule raison d’être de l’environnement de simulation est de vous aider à préparer la déclaration définitive que vous introduirez en production.

      Il est donc important que vous fassiez bien la différence entre simulation et production et que vos déclarations soient toujours introduites dans l’environnement adéquat.

      Recommandations

      L’environnement de simulation vise seulement à aider à la préparation des déclarations définitives en production. Il est donc vivement conseillé d’être attentif aux deux règles suivantes dans l’environnement de simulation :

      • Limitez le nombre de déclarations AccountState (p. ex. max 1000) transmises par fichier de déclaration (fichier xml). En simulation, une performance similaire à celle de l’environnement de production ne peut en effet être garantie. Les plus grands volumes d’input (des déclarations accompagnées d’une identification d’individus) peuvent ralentir le traitement en simulation et auront pour conséquence des temps de réponse plus longs (tant pour vous que pour les autres utilisateurs). Nous déconseillons donc de charger en simulation le portefeuille complet comprenant tous les affiliés.
      • N’utilisez pas l’environnement de simulation DB2P comme outil pour l’identification des individus. Seuls les résultats de l’identification exécutée via le preload ou l’environnement de production DB2P peuvent être considérés comme une référence et utilisés dans des déclarations ultérieures. Pour les déclarations DB2P en simulation, l’identification des individus s’effectue avec par exemple un numéro BIS sur base d’une banque de données de test. Les données de cette banque de données de test peuvent différer des données officielles dans le registre de la BCSS.

       

  6. Table des versions

    La table des versions permet de vérifier quelles versions des instructions, du XSD et de la liste des anomalies sont liées entre elles, lesquelles sont actives et lesquelles sont compatibles.

    Que signifient les numéros de version ?

    Les instructions de déclaration, les XSD et les listes d’anomalies comportent chacun un numéro de version. Les instructions ont un numéro de version en deux parties : AA.BB. La première partie (AA) du numéro change en fonction de modifications substantielles du champ d’application. La seconde partie (BB) indique de quelle version des instructions il s’agit dans le cadre du champ d’application en vigueur. La version 01.04 concerne dès lors la quatrième version des instructions dans le cadre du champ d’application décrit dans les instructions.

    Le XSD suit une numérotation technique qui est notamment liée aux applications sous-jacentes chez Sigedis. Elle se compose de trois parties : AA.BB.CC. Les éléments donnent une indication de l’impact relatif des différences entre les versions successives. Un changement dans la première partie (AA) signifie qu’il s’agit d’une modification importante (major) qui dans la plupart des cas aura pour conséquence une perte de la backwards compatibility par rapport aux versions antérieures. Un changement dans la deuxième partie (BB) indique une plus petite adaptation (minor), importante pour le déclarant, mais sans impact sur la backwards compatibility. Enfin, une modification dans la troisième partie (CC) signifie qu’il s’agit d’une adaptation minime (micro) qui n’impacte pas la backwards compatibility et qui en principe n’a que des conséquences internes pour Sigedis.

    1. LPC

      Status     

      Date

      Application 
      release note

      New functionalities

      XSD

      Archive 18/10/2016 01.25
      no new functionalities
       
      03.07.00
      Active 26/10/2017 01.26

      Declaration (Limited)EventAccountState
      Online & batch
      New EventTypes added: 
      DepartureChoiceDeath, EndAffiliationDeath, EndAffiliationRetirement & PartialPayment
       

      Simulation & Production
       

      Declaration mandatory from: 1/1/2018
      03.09.00
       
    2. Autres LPC

      Status     

      Date

      Application 
      release note

      New functionalities

      XSD

      Archive 23/03/2016 01.25 New functionalities for WAP (New optional fields: VariableElements) but not for AWAP 01.02.00
      Active 26/10/2017 01.26

      Declaration (Limited)EventAccountState
      Online & batch
      New EventTypes added: DepartureChoiceDeath, EndAffiliationDeath, EndAffiliationRetirement & PartialPayment 

      Simulation & Production
       

      Declaration mandatory from: 1/1/2018
       
      01.04.00