Les erreurs évitables disparaîtront et on procèdera uniquement avec les erreurs bloquantes ou les avertissements. En outre, les règles de validation sont entièrement remaniées dans un souci de clarté et de simplification.

Les données telles qu’indiquées dans les avis aux débiteurs restent obligatoires à déclarer. Afin de faciliter le traitement de la fiche et son affectation au bon dossier, nous vous recommandons d’introduire la fiche de la manière la plus complète possible, en remplissant les champs non obligatoires si possible.

Les fiches pour l’année de revenus 2025 devront être introduites dans la nouvelle application, celles pour les années de revenus antérieures dans l’ancienne application.

Java n’est pas nécessaire pour la nouvelle application.

Il n’y aura plus de module de validation téléchargeable disponible. Toutefois, si vous le souhaitez, vous pouvez vérifier les règles de validation en envoyant un fichier test dans l’application.

Non, il n’est plus obligatoire de numéroter une fiche de manière consécutive.

La brochure globale de BOW 2.0 sera publiée en décembre 2025, comme chaque année. En effet, nous devons tenir compte des modifications législatives qui peuvent encore être mises en œuvre jusqu’à la fin de l’année.

La démo définitive sera publiée au plus tard début 2026. Avant cette date, des démos de l’application seront prévues par le biais de différents canaux.

Non, les mandats ne seront pas utilisés. La gestion des rôles actuel continuera à s’appliquer.

Il faut scinder les données dans la mesure du possible. Lorsque ce n’est pas possible, il faut indiquer l’adresse complète dans la propriété « s » qui correspond à la rue.

Plutôt que de travailler avec des balises XML pour définir les différentes zones, le nouveau système utilise des propriétés JSON qui, pour la plupart des zones, sont constitués d'un code numérique à quatre chiffres. Ce code numérique reste identique à celui déjà présent dans les balises XML pour la plupart des zones. Par exemple, la zone 2.060 de la fiche 281.10 qui était défini par la balise « f10_2060_gewonebezoldigingen » dans le XML sera maintenant défini par la propriété « 2060 » en JSON.

L’ordre des balise est libre. Vous pouvez reprendre en premier lieu les zones obligatoires, suivies des zones facultatives, mais ce n’est pas obligatoire.
 

Chaque fiche doit avoir une key unique afin d’éviter toute double introduction de la fiche. Cette key unique présente l’avantage de permettre à un utilisateur d’adapter facilement la bonne fiche si nécessaire.

L’expéditeur peut attribuer plusieurs références à une entité, tant pour les débiteurs que pour les bénéficiaires. Les entités seront conservées par expéditeur afin qu’aucun autre expéditeur ne puisse écraser les fiches.  
 

Il vous est recommandé de faire la distinction en utilisant un autre préfixe dans la référence du débiteur.
 

Les fichiers .XML peuvent encore être introduits dans l’ancienne application pour un nombre limité d’années, à savoir l’année de revenus 2024 et les années antérieures. Toutefois, à partir de l’année de revenus 2025, seuls les fichiers JSON Lines sont autorisés.
 

Les montants négatifs ne sont pas autorisés. Il n’est pas non plus utile de remplir les champs vides d’un « 0 », puisque « 0 » a une signification différente dans certains champs et ne correspond donc pas à un champ « vide ».
 

Lorsqu’un envoi est refusé dans son intégralité, vous devez, après correction, le réexpédier intégralement. Toutefois, s’il s’agit d’un envoi partiellement approuvé, vous pouvez réexpédier l’envoi intégralement ou ne renvoyer que les fiches corrigées qui contenaient précédemment des erreurs.

Les fiches contenant des erreurs ne seront pas traitées. Seules les fiches correctes sont validées. Vous pourrez demander les données de ces fiches erronées pour que vous puissiez les corriger si vous le souhaitez et les introduire à nouveau ultérieurement.
 

Si votre fichier contient au maximum 5 % d’erreurs, et pas plus de 100 fautes au total, il sera accepté à l’exception des fiches erronées. Ces fiches erronées ne seront pas validées et vous devrez les renvoyer. Si votre fichier contient plus de 5 % d’erreurs ou plus de 100 fautes, votre envoi sera rejeté dans son intégralité.
 

Il est possible de le faire en utilisant une autre référence de fiche. Si plusieurs endroits s’appliquent au débiteur, il est utile de créer une référence différente de ce débiteur pour chaque endroit.

Le préambule peut être envoyé quotidiennement. Nous vous conseillons de ne pas charger chaque jour à nouveau l’ensemble du portefeuille d’entités, mais de charger uniquement les modifications.

• Si aucune modification n’apparaît dans le préambule, les données envoyées ne changeront pas.
• À l’inverse, si des modifications ont lieu dans le préambule, c’est-à-dire l’apparition de données supplémentaires, ces données supplémentaires seront créées.
• Si une donnée est supprimée dans le préambule :
  • par exemple la suppression d’une entité : les fiches existantes sont conservées tout comme les entités qui sont liées à des entités. Mais vous ne pourrez plus réutiliser la key qui a été supprimée dans cette entité supprimée, étant donné qu’elle a été mise sur non active.
  • par exemple la suppression d’une adresse : il s’agit d’une modification apportée comme étant une mise à jour de l’entité, mais les fiches originales avec les données afférentes à l’entité sont conservées.

Le système ne génère plus d’e-mail automatique. Vous pouvez à tout moment demander du feedback dans l’application. Pour autant que vous disposiez du même rôle, vous pouvez également demander du feedback sur des fiches précédemment introduites par un collègue.
 

Oui, il est toujours possible d’introduire des fiches via l’application, soit par l’envoi d’un fichier, soit par le codage dans les écrans.
 

Vous pouvez éviter cette situation en plaçant le préambule et les fiches dans un seul fichier. Toutefois, si vous souhaitez les introduire séparément, nous vous conseillons d’attendre l’acceptation du préambule avant d’envoyer les fiches puisque ces dernières renvoient aux données du préambule.

Les développements pour le démarrage de l’API sont en cours. Dès que les développements techniques seront validés, nous publierons les informations nécessaires sur notre site web.
 

L’envoi de fichiers volumineux reste possible. Ces envois devront être établis en JSON Lines. Les envois de type .XML disparaîtront donc effectivement à partir de l’année de revenus 2025.
 

Non, aucun module de conversion n’est prévu. Il est donc recommandé de se mettre à travailler à temps avec les fichiers fournis.

Par la transmission d’une fiche modificatrice, l’ancienne fiche est désactivée et la nouvelle est activée. Toutefois, il sera possible de consulter la fiche initiale.