N Questions/Remarques Réponses CBC,…) Wat invullen in ... · Date impression : 17/12/2010 Page 3...

Date impression : 17/12/2010 sur 25

Statut : Approuvé

Contact : [email protected] DateVersion : 20122010v3

N

°

Questions/Remarques Réponses

1 Hoeveel files moeten we aanmaken ?

- 1 per paying agent (dus 1 KBC, 1 CBC en 1 Centea) ?

C’est bien évidemment ce qui est demandé. Un fichier par agent payeur (KBC,

CBC,…)

2 Wat invullen in Message ID : volgens richtlijn moet dit

uniek zijn over “space and time”

1 deel is landcode van de afzender, dus vermoedelijk BE

Ander deel is een identifier. Wat moeten we hier invullen

?

En is het de bedoeling om bij een correctie of aanvulling

dan ook de vorige Message ID in te vullen ?

Cfr. point II.2 du protocole JMonnet. Le MessageID est unique dans le temps

et dans l’espace. Par conséquent, on ne peut le réutiliser dans aucun message

ultérieur même en cas de correction spontanée. Dans ce cas précis, il y a lieu de

générer un nouveau MessageID tout en reprenant dans CorDocRefID

l’identifiant du record initial à corriger.

3 Moeten we antwoord op vraag correcties automatiseren

?

En zo ja, hoe zit het met weigering van deze aanvragen ?

Actuellement les demandes de correction ne sont pas traitées de façon

automatique. Elles seront traitées manuellement au cas par cas en utilisant

notamment, la liste des personnes de contact par institution financière (agent

payeur) fournie par FEBELFIN au SPF FINANCES.

4 Structuur DOCrefID

Welke aanduiding voor Residuele entiteit gebruiken : RE ?

Cas : code Identifiant Long Exemple

Agent Payeur : PA

[BE][XXXXXXXXXX][-PA-] [YYYY]-[NNNNNN]

27 BE0403201185-PA-2011-000001

Bénéficiaire effectif : BO

[BE][XXXXXXXXXX][-BO-] [YYYY]-[NNNNNN]

27 BE0403201185-BO-2012-000001

Entité résiduelle : RE

[BE][XXXXXXXXXX][-RE-] [YYYY]-[NNNNNN]

27 BE0403201185-RE-2013-000001

Paiement : Art9 [BE][XXXXXXXXXX][-ART9-] [YYYY]-[NNNNNN]

29 BE0403201185-ART9-2015-000001

Paiement : Art4.2

[BE][XXXXXXXXXX][-ART4.2-] [YYYY]-[NNNNNN]

31 BE0403201185-ART4.2-2016-000001

o [XXXXXXXXXX] correspond au numéro BCE

(Banque Carrefour des Entreprises) de l’agent


Statut : Approuvé


payeur, o YYYY : année en cours,

NNNNNN : indicateur numérique composé de 6 chiffres de séquence, réinitialisé chaque année.

5 Wat zijn de gevolgen als een cliënt 2 maal gerapporteerd

wordt (dubbele cliëntnummers) ?


Statut : Approuvé


Selon l’XSD ci-dessus, il est tout à fait possible de renseigner un seul client

avec autant de paiements que nécessaire. Par ailleurs, le même client peut être

référencé, également, différemment au sein de la même banque.

6 Is 7 jaar corrigeren een verplichting ? (of wordt dit

overgelaten aan de banken zelf ?)

La durée de 7 ans est basée sur la législation belge en la matière.

7 Wat bedoelt men met “4. En ce qui concerne les champs

obligatoires tels que définis par la Commission de l’UE,

Selon l’XSD FISC 153 certains champs sont obligatoires est donc il faut

fournir les données auxquels ils se rapportent. D’autres champs sont optionnels


Statut : Approuvé


ceux-ci doivent être respectés. Les champs optionnels

pour lesquels il …document restent en toute hypothèse

optionnelle. Le cas échéant une mention ‘unknown’ ou

une autre mention par défaut (exemple : x) doit être

mentionnée ».

est par conséquent, l’institution financière n’est pas obligée de les fournir sauf

pour améliorer la qualité des données transmises.

8 MessageTypeIndic - waarde 3 (cancellation)

fisc 153 : pg. 18 : gereserveerd voor toekomstig

gebruik

protocole_Jmonnet : pg. 5 : zal wel gebruikt kunnen

worden. Betekent dit dat het annulatieproces intussen wel

verder uitgewerkt is en dat we ons op protocole_jmonnet

mogen baseren : dus mogelijkheid om waarde 3 wel in te

vullen en te gebruiken ?

L’actuelle version du protocole ne préconise plus le chiffre 5 pour les tests.

Cette option est offerte par un environnement de tests indépendant de celui de

la production. Par ailleurs, il est effectivement possible d’utiliser le code 3 pour

annulation.

9 Zal in geval van vragen van de buitenlandse fiscus een

refertenummer van de fiscus zelf (buitenlandse of

Belgische) meegegeven worden ?

Indien wel : Stel dat we deze referte intern zouden willen

opslaan ifv opzoekingen, hoe zal deze referte eruit zien ?

We zouden dit dan evt. in onze database al kunnen

voorzien en toekomstige aanpassingen vermijden in ons

datamodel.

A ce jour rien n’est prévu pour les demandes d’informations complémentaires

pour les identifier moyennant une référence unique. Ceci devrait faire partie

d’une procédure annexe manuelle qui ne fait pas partie de cette phase du projet.

1

0

In de documenten Jmonnet die in februari verspreid zijn, is

er sprake van testaanleveringen. Hiervoor moeten we

MessageTypeindic op 5 zetten.

De printscreens voor de upload hebben 2 knoppen :

Nous avons séparé les écrans de test de ceux de production. Par conséquent, il

n’est plus nécessaire d’indiquer le chiffre 5 pour “test”. Il faut indiquer le bon

chiffre selon vos scénarios de test (nouveaux cas, annulation, les deux à la

fois).


Statut : Approuvé


enerzijds opsturen - anderzijds opsturen als test

Hoe moeten we dit interpreteren ?

- Moet een file met MessageTypeIndic op 5 steeds

afgestaan worden via de testknop ?

of

- Kan je die file ook via de gewone knop afstaan

waarbij dan door de waarde van MessageTypeIndic die

file als testfile verwerkt zal worden ?

Omgekeerd :

- Mogen we een file met een MessageTypeIndic

verschillend van 5 ook afstaan via de testknop ? En zal

deze file dan zeker als test behandeld worden ?

1

1

De printscreens uit de documenten Jmonnet van februari

printscreens zullen de waarde voor "nombre

d'enregistrements" teruggeven.

Slaat dit op het aantal PaymentData's die in de XML file

zitten ? Dus het totaal aantal keer dat een PaymentData

gerapporteerd wordt over de hele file heen (dus voor

verschillende artikels (4.2/9) en verschillende paying

agents en beneficial owners) ?

Effectivement, il s’agit du nombre total des paiements (PaymentData) repris

dans le fichier. Attention, il n’y a qu’un seul “Paying Agent = banque” par

fichier.

1

2

Het LegalAdressType is een optioneel veld voor een

residuele entiteit. Welk is het legaladresstype voor een

residuele enititeit ?

Cfr. Fisc79 (5.2.2.4) :

The legalAddressType_Type is used to describe the legal character of an

address. It is based on the legalAddressType_Type of the STF:


Statut : Approuvé


<xsd:simpleType name="legalAddressType_Type">

<xsd:restriction base="xsd:token"> <xsd:enumeration value="residentialOrBusiness"/> <xsd:enumeration value="residential"/>

<xsd:enumeration value="business"/> <xsd:enumeration value="registeredOffice"/> <xsd:enumeration value="unspecified"/>

</xsd:restriction>

</xsd:simpleType>

XML Fragment 1: legalAddressType_Type (STF)

For the purposes of the Savings Directive, “fiscalResidence” is added: <xsd:simpleType name="legalAddressType_Type"> <xsd:union memberTypes="stf:legalAddressType_Type"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="fiscalResidence"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>

XML Fragment 2: legalAddressType_Type (SDF)

Value Description

residentialOrBusiness The address is either a residential or business address

residential The address is residential

business The address is business

registeredOffice The address is the registered office of the legal person

unspecified The nature of the address is not specified

fiscalResidence The address is for fiscal purposes (this is relevant for Beneficial

Owner only)

Table 1: Allowed values of the legalAddress_Type


Statut : Approuvé


5.2.2.5. Address_Type

The Address_Type allows either a structured address (AddressStruct) or a free

format address (AddressFree). The CountryCode of the address is provided

separately from these types and is mandatory.

Whenever possible, the AddressStruct element must be supplied, even if only

partial details from the address can be matched to an element (for example a

postal code or city). The AddressFree can be used to supplement an incomplete

AddressStruct.

The optional legalAddressType attribute allows the type of address to be

provided, from among the values in Table 1, if this is known.

Figure 1: Address_Type


Statut : Approuvé


<xsd:complexType name="Address_Type"> <xsd:sequence> <xsd:element name="CountryCode" type="dt:CountryCode_Type"/> <xsd:choice> <xsd:element name="AddressFree" type="xsd:string"/> <xsd:sequence> <xsd:element name="AddressStruct" type="sd:AddressStruct_Type"/> <xsd:element name="AddressFree" type="xsd:string" minOccurs="0"/> </xsd:sequence> </xsd:choice> </xsd:sequence> <xsd:attribute name="legalAddressType" type="sd:legalAddressType_Type" use="optional"/>

</xsd:complexType>

XML Fragment 3: Address_Type

1

3

Structuur DOCrefID : Welke aanduiding voor Residuele

entiteit gebruiken : RE ?

Cas : code Identifiant Long Exemple

Agent Payeur : PA

[BE][XXXXXXXXXX][-PA-] [YYYY]-[NNNNNN]

27 BE0403201185-PA-2011-000001

Bénéficiaire effectif : BO

[BE][XXXXXXXXXX][-BO-] [YYYY]-[NNNNNN]

27 BE0403201185-BO-2012-000001

Entité résiduelle : RE

[BE][XXXXXXXXXX][-RE-] [YYYY]-[NNNNNN]

27 BE0403201185-RE-2013-000001

Paiement : Art9 [BE][XXXXXXXXXX][-ART9-] [YYYY]-[NNNNNN]

29 BE0403201185-ART9-2015-000001

Paiement : Art4.2

[BE][XXXXXXXXXX][-ART4.2-] [YYYY]-[NNNNNN]

31 BE0403201185-ART4.2-2016-000001

o [XXXXXXXXXX] correspond au numéro BCE

(Banque Carrefour des Entreprises) de l’agent payeur,

o YYYY : année en cours, NNNNNN : indicateur numérique composé de 6 chiffres de séquence,


Statut : Approuvé


réinitialisé chaque année,

1

4

Cfr. JMonnet februari pg. 2

Ligt er al een limiet vast wat betreft grootte orde bestand ?

Is al geweten of file in ZIP formaat moet afgestaan worden

?

Cette information sera donnée après les premiers tests avec MyminfinPro. Les

fichiers sont automatiquement compressés lors du transfert donc il n’y a pas

lieu de le faire avant.

1

5

Wat bedoelen ze met "4. En ce qui concerne les champs

obligatoires tels que définis par la Commission de l’UE,

ceux-ci doivent être impérativement respectés. Les

champs optionnels pour lesquels il n’est pas dérogé dans le

présent document restent en toute hypothèse optionnelle.

Le cas échéant une mention ‘unknown’ ou une autre

mention par défaut (exemple : x) doit être mentionnée"

Velden worden als verplicht of optioneel aangeduid in de XML-schema’s. De

tabellen in fisc 80 (pg 118 – 125) geven naast de indicatie verplicht/optioneel

ook aan of een lege waarde toegelaten is of niet. Geeft dit problemen indien

toch een blanco waarde afgestaan wordt ?

� veld optioneel en lege waarde indicator in fisc 80 staat op N : dan mag dit

veld dus niet afgestaan worden ?

Nous disons bien :

“…Les champs optionnels pour lesquels il n’est pas dérogé dans le présent

document restent en toute hypothèse optionnelle. Le cas échéant le mot

‘unknown’ doit être mentionnée"

1

6

We moeten rekening houden met een mogelijke

versiewissel van het XSD-schema.

Mogen we van de veronderstelling uitgaan dat een

versiewissel steeds gekoppeld zal zijn aan een

inkomstenjaar ?

Ik bedoel daarmee dat als een wisseling van versie zal

gebeuren, moeten we dan bv de XML van de vorige

inkomstenjaren met de vorige versie en van de komende

Cette matière ne dépend pas du SPF FINANCES, ceci relève des compétences

de la Commission Européenne et du groupe de travail ACDT.

A priori, en cas de nouvelle version, ces deux organismes préciseront la

démarche à suivre.


Statut : Approuvé


inkomstenjaren met de nieuwe versie maken ?

1

7

MessageTypeIndic in de header

- Volgens JMOONET wordt de waarde 4 (nieuw en

correcties) niet langer gebruikt

- Maar als je dan een spontane correctie doet (vb 30/6)

- de gewijzigde gegevens krijgen in de

DocTypeIndic de waarde "2" van wijziging

- de nieuwe gegevens zouden dan in de

DocTypeIndic de waarde "1" van nieuw krijgen

- Maar als je dan de regels rond MessageTypeIndic en

DocTypeIndic gaat nalezen mag je dus blijkbaar

MessageTypeIndic "2" niet combineren met een

DocTypeIndic "1"

Moeten we dan in dit geval 2 XML-rapporteringen gaan

aanmaken, 1 voor de nieuwe gegevens en 1 voor de

gewijzigde gegevens ?

Zou nog logisch zijn als je een volledig nieuwe BO hebt

maar als je als een BO doorgestuurd hebt en daar nog

payments aan moet toevoegen ga je eigenlijk in nog eens

diezelfde BO moeten doorsturen ?

La nouvelle version du protocole permet d’utiliser le MessageTypeIndic de

valeur = 4 pour pouvoir mettre dans le même fichier FISC 153 des

informations nouvelles et des annulations.

1

8

1ère situation

En 2010, le client a reçu 10.000 EUR d’intérêts sur son compte

à terme. La banque ne déclare pas (pour quelque que raison

que ce soit) ce « paiement d’intérêts » dans le reporting 2011

1ère situation :

La banque doit communiquer cette information en tant que nouvelle

déclaration avec un numéro de référence unique tout en précisant dans le

champ ad hoc l’année du paiement (cfr. FISC 80).


Statut : Approuvé


(relatif aux « paiements d’intérêts » attribués en 2010).

Comment doit-elle procéder pour communiquer par après

cette information ?

1er

possibilité : dans un reporting suivant (relatif aux

« paiements d’intérêts » de l’année au cours de laquelle

l’absence de déclaration est constatée, comme s’il

s’agissait d’un « paiement d’intérêts » fait ou attribué au

cours de cette année là).

2ème

possibilité : au moyen d’une déclaration corrective (du

reporting 2011) mais dans ce cas, sans pouvoir mentionner

un « numéro de référence unique » puisqu’il n’y a pas eu

de communication initiale d’informations.

2ème situation

En 2010, le client n’a reçu aucun « paiement d’intérêts ». Rien

n’est déclaré dans le reporting 2011 (relatif aux « paiements

d’intérêts » attribués en 2010). Plus tard, la banque se rend

compte d’une erreur (quelque soit la raison de cette erreur) : le

client avait droit, en 2010, à un intérêt de 500 EUR.

Comment doit-elle procéder pour communiquer cette

information ?

1er

possibilité : dans un reporting suivant (relatif aux

2éme situation :

Idem situation 1.

Réponse à la question générale :

La banque doit corriger ou annuler l’opération du passé en effectuant une

déclaration individuelle limitée au « paiement d’intérêts » à corriger ou à

annuler. Cette correction peut être faite au sein d’un fichier contenant de

nouvelles déclarations.


Statut : Approuvé


« paiements d’intérêts » de l’année au cours de laquelle le

« paiement d’intérêts » est finalement fait ou attribué).

2ème

possibilité : au moyen d’une déclaration corrective (du

reporting 2011) mais dans ce cas, sans pouvoir mentionner

un « numéro de référence unique » puisqu’il n’y a pas eu

de communication initiale d’informations.

Question générale

Dans l’hypothèse d’une correction ou d’une annulation d’un

« paiement d’intérêts » déclaré dans un reporting précédent, la

banque doit-elle corriger ou annuler l’opération du passé en

effectuant une déclaration individuelle (reporting) limitée au

« paiement d’intérêts » à corriger ou à annuler ?

OU peut-elle envoyer un tout nouveau reporting complet pour

l’année concernée (sorte de mise à jour d’une version

précédente qui remplace cette version précédente) et dans ce

cas, combien de fois par an ?

1

9

Les critères de cumul :

Question : Allez-vous garder au niveau belge

l'Art9PaymentData comme défini dans le document FISC

135 ?

Partant de cette hypothèse, peut-on en déduire que le

regroupement se fera par les palliers suivants :

1) Par BO / Pays de résidence ;

2) Par SpecificPaymentType ;

Le SPF FINANCES fait uniquement le dispatching vers les pays destinataires

et rien d’autres. Ce dispatching se base sur le code pays de résidence du

bénéficiaire.


Statut : Approuvé


3) Par Devise;

4) Par compte.

Si cette hypothèse est retenue, comment définir un

DocRefId pour l'article 9 de paiement ? Si je garde le

schéma actuel de l'art9 de paiement, cela voudrait-il dire

que si j'ai dans un même type de paiement deux devises,

j'aurai un même DocRefId pour les deux paiements ? Ou

alors si j'ai deux comptes qui ont reçu les paiments, ces

deux comptes auront le même DocRefID ?

2

0

Autre point d'interrogation : à la page 7 de la V3 du

document 'Protocole JMONNET' , vous définissez la

structure du DocRefID pour le PA, le BO, l'Art9 de

paiement et l'Art4.2 de paiemnet.

Nulle part je ne trouve la définition de cette structure pour

une Entité Résiduelle. Est-ce à dire que celle-ci n'a pas

besoin d'avoir une référence unique ?

Cfr. Question 13 de ce document.

2

1

Een klant van de financiële instelling in België woont

gedurende 6 maand in Frankrijk en heeft daar ook zijn

fiscale residentie maar verhuist in juli naar België en

behoudt zijn fiscale residentie in Frankrijk. De intresten

worden toegekend per einde jaar dus op het moment dat

zijn woonplaats in België is maar zijn fiscale residentie

nog steeds in Frankrijk.

We moeten dus informatie uitwisseling doen maar onze

vraag is welke adres we moeten opgeven in de XML file.

Het adres op moment van betaling van intresten, zijnde het

L’adresse à indiquer dans l’XML est toujours l’adresse de la résidence fiscale.


Statut : Approuvé


adres in België of zijn oorspronkelijk adres in Frankrijk?

2

2

betreft de reporting van “intrestbetalingen” waarvan de Uiteindelijk Gerechtigde (UG) een gelijkgesteld niet-inwoner is.

Voorbeeld : De heer Dupont is een Europese ambtenaar

met een wettelijk adres in Brussel en een fiscale

woonplaats in Frankrijk (zoals vermeld op attest HIS 276)

Hij heeft een termijnrekening bij een Belgische bank die

1.000 EUR in de loop van 2010 opbrengt. Hoe zal de

Belgische bank doen om die situatie te rapporteren ?

Voorstel : Op het document FISC153 (bladzijde 41) staat

de structuur vermeld voor wat betreft The Beneficial

Owner. Er zijn twee vaken : ResCountryCode en Address –

CountryCode. Zou de Belgische bank het vak

ResCountryCode kunnen gebruiken om de Tax Country

van de UG te communiceren ? Op basis daarvan zou de

Belgische fiscus weten naar welke EU lidstaat deze info

moet worden doorgestuurd ? Is dat (praktisch gezien)

aanvaardbaar ?

Cfr. Réponse 21.

Pratiquement dans ce cas, ResCountryCode= Fr puisque c’est le pays de la

résidence fiscale comme declaré dans le document HIS 276.

2

3

Voor Residuele Entiteiten (Art.4_2) dienen we cfr. jullie

informatie in vrije text de naam van de gerechtigde (the name

of the Beneficial Owner ) mee te delen.

BASE:

Cfr. Protocole.

Le nom de l’entité résiduelle ne peut qu’être « free ».


Statut : Approuvé


/dt:DirectTaxMessage/dt:Body/sd:InitialElements/sd:Article4_2 LOCATION: sd:Entity/NameFree

Figure 10 - Name of the Entity

The NameFree element allows entering the name of the

entity as free text. It has an optional attribute, nameType,

which can take one of the following values, inherited from

STF:


Statut : Approuvé


Maar in het xsd-schema is (NameFree) een groepsveld en geen element dat een waarde kan bevatten ??? <xsd:complexType name="EntityParty_Type"> <xsd:sequence> <xsd:element name="OtherInfo" type="sd:OtherInfo_Type"/> <xsd:element name="NameFree" type="sd:EntityName_Type"/> <xsd:element name="Address" type="sd:Address_Type"/> </xsd:sequence> <xsd:attribute name="oecdLegalType" type="stf:oecdLegalType_Type" use="required" fixed="06"/> </xsd:complexType>

Kunnen jullie ons hiermee verder helpen aub. ?


Statut : Approuvé


2

4

Vraag rond de paying agent bij splitsen files :

Wanneer we een file moeten splitsen owv volumes

hoe moeten we dan de files aanmaken

optie 1

1e file : initial elements (met een paying

agent)

2e file : initial elements met een nieuwe

paying agent (dus nieuwe docreferte maar met dezelfde

gegevens als die van file 1)

optie 2

1e file : initial elements (met een paying

agent)

2e file : spontane correcties voor paying

agent met nieuwe beneficial owners en paying agents

C’est l’option 1.

File 1 : - Header 1– body 1(PA1 + BO1)

File 2 : - Header 2– body 2(PA1 + BO2)

2

5

Based on the documentation available on the febelfin extranet, we are building a solution

1. acctNoQlf : It’s a free text zone so you should indicate the real type of the

account number.


Statut : Approuvé


to generate the XML DirectMessageTag. After a detailed analysis of the available specifications, we still have a few questions. We would appreciate if you could take the time to answer them or to forward this message to the appropriate persons. 1) What is the list of possible values for the attribute acctNoQlf of the OBAN element? Or is a it free text we can fill as we like? The account structure we use at Petercam is 1-5-2 which is neither an IBAN nor a BBAN number. We therefore have to use the OBAN element. This element has a *compulsory* acctNoQlf allowing to indicate which type of account is used. In the sample xml file downloaded from the febelfin extranet, we noted that this attribute was always set to "BBAN". --> So, as our account structure is not a BBAN, what value should we use to fill in the attribute acctNoQlf? 2) What is the list of possible values for the attribute secNoQlf of the OSIN element? Or is a it free text we can fill as we like? 3) What is the list of possible values for the attribute othQlf of the OtherPersData element? Or is a it free text we can fill as we like?

2. secNoQlf : It’s a free text zone so you should indicate the real type of the

security number.

3. othQlf : It’s a free text zone wich allow you to indicate more specific

personal.


Statut : Approuvé


2

6

Worden volgende wijzigingen effectief van kracht vanaf 01/01/2011:

1) afschaffing grootvaderclausule:

In FAQ van Febelfin op p. 14 staat ivm grootvaderclausule: 'In principe is de clausule van toepassing tot 31 december 2010.' Waarom staat er 'in principe' ?

2) wijziging van drempel van 40% naar 25% bij verkoop of terugbetaling op vervaldag van beveks:

Momenteel is de verkoop of terugbetaling op vervaldag

van beveks die minder dan 40% beleggen in rentedragende

producten niet onderworpen aan Europese spaarfiscaliteit.

Wijzigt 40% naar 25% vanaf 01/01/2011 ?

1. La clause de grand-père s’achève bien le 31/12/2010 pour les agents payeurs

belges. L’expression « en principe » n’est plus pertinente. Le fait que la

Belgique ait basculé dans le système d’échange d’informations a pour

conséquence que la clause de grand-père ne peut pas être prolongé en Belgique

au delà du 31/12/2010.

2. A compter du 1/1/2011, le seuil de 40% passe bien à 25%. Pour les cessions/

remboursements/rachats de parts d’OPCVM faits à partir de cette date, il

convient donc d’appliquer le seuil de 25% pour déterminer si le paiement

tombe dans le champ d’application de la directive et, si oui, effectuer l’échange

d’informations.

2

7

1) In verband met het TIN-nummer heeft de fiscus een document uitgewerkt waarin voorbeelden van ID-kaarten van verschillende betrokken landen vermeld staan en waarin uitgelegd wordt waar men het TIN-nummer op de betreffende ID-kaart kan terugvinden. Men zou het document in principe moeten terugvinden op Fisconet door op een link in bijlage n°6 van de circulaire Ci.R.9.Div./602/285 (AOIF nr 25/2010) dd 12.03.2010 te klikken maar deze link werkt niet. Zou u ons het document kunnen bezorgen? 2) Waarom moeten we niet-residenten identificeren vai het TIN-nummer? Mag dit niet

1. En ce qui concerne le lien pour les Numéros d'Identification Fiscal (NIF), le bon lien

est bien : http://fngsvvmefiscd01/interfaoiffr/Werkgevers/Fichesopgaven/nif.htm Vous pouvez également accéder à cette page de la manière suivante : sur le site www.minfin.fgov.be, choisir "Administrations" --> "Impôts et Recouvrement" --> "Fiscalité des entreprises et des revenus" ou sur www.fiscus.fgov.be. Sur ce site, sous la rubrique "Avis aux employeurs et débiteurs de revenus" choisir "fiches et relevés (Fr, De, Nl) puis sur le lien

NUMERO D'IDENTIFICATION FISCALE (NIF)

2. A partir du moment où l’information est disponible, ce TIN est


Statut : Approuvé


gewoon via naam, voornaam, geboortedatum, geboorteplaats, ...? 3) Op basis van welke criteria moeten interesttransacties gegroepeerd worden vooraleer ze worden doorgestuurd naar Minfin. zelfde persoon, type contract, munt, fiscale woonplaats, ...

impérativement à mentionner en plus.

3. Il faut regrouper par Personne, Type de contrat, Type de compte, Devise et

adresse fiscale

2

8

Verschillende uitkeringen van intresten op eenzelfde product mogen geglobaliseerd worden in de rapportering – is het ook toegestaan om verschillende uitkeringen van intresten in detail te rapporteren?

Voorbeeld: termijnrekening met

plaatsing 1 van januari 2010 tem juni 2010

plaatsing 2 van juli 2010 tem december 2010

� hebben we de keuze in de gegevensuitwisseling om plaatsing 1 en 2 apart te rapporteren of te globaliseren?

Les agents payeurs belges peuvent, bien entendu, effectuer deux fournitures

d’informations lorsque plusieurs payements d’intérêts sont globalisés sur un

même produit.

Dans l’exemple ci-contre, les agents payeurs belges devraient pouvoir effectuer

2 échanges d’informations. Cela peut s’avérer utile pour l’Etat membre qui

reçoit l’information. En effet, entre les 2 échéances (juin et décembre 2010), le

revenu pourrait être rattaché à 2 exercices fiscaux différents, le bénéficiaire

effectif pourrait avoir changé d’Etat membre de résidence ou même le

bénéficiaire effectif pourrait ne plus être la même personne.

2

9

Vraag 1:

Bij opmaken van een record zijn er verschillende

elementen die mogelijk als uniek kunnen beschouwd

worden. Men kan uniek werken op naam,

rekeningnummer met als bijkomende onderverdeling per

type betaling of munt. Welk is de structuur of volgorde

(key) die dient gerespecteerd te worden?

1. Pour un même produit, les différents paiements d'intérêts peuvent en effet

être globalisés. Par contre, les paiements d'intérêts d'une même catégorie mais

correspondant à plusieurs produits différents (exemple : plusieurs comptes

bancaires distincts) ne devraient pas être globalisé.

2. La circulaire peut être consultée via le portail des Finances (Fisconet plus)


Statut : Approuvé


Mag men bij aangifte voor fysieke personen (article 9)

iedere betaling als een aparte record beschouwen? Of dient

men totalen te maken per PayementType?

Vraag 2:

Tijdens de infosessie van 16 september heeft Dexia hun

project toegelicht. Ook hebben zij gemeld welke

informatie er ter beschikking is. Een van de belangrijke

was: Administratif circular dd 12/03/2010. Zou u ons

kunnen melden waar wij deze kunnen bekomen?

Vraag 3:

Bank X is een Commanditaire Vennootschap op Aandelen

dient men dan als oecdLegalType “03” gebruiken

(Partnership)?

Vraag 4:

In MonAmnt dient men het “gross amout” ingeven m.a.w.

het bruto bedrag. Indien er echter 15% Roerende

Voorheffing is afgehouden dient men dan het netto of

bruto vermelden?

Vb: In een onverdeeldheid van 4 zit een begunstigde die in

een ander europees land vertoeft. Er wordt 100 euro brut

uitbetaald maar min 15% roerende voorheffing. Zal men

dan 25 euro (brut) aangeven voor deze persoon of 21 euro

(net)?

Vraag 5:

Bij uitbetaling van een buitenlandse obligatie waar reeds

buitenlandse taks afgehouden werd door de uitbetalende

buitenlandse instantie (of correspondent) dient men dan bij

uitbetaling aan een klant aangifte te doen van bruto? Of

3. Nous ne comprenons pas la question puisque « oecdLegalType” concerne

uniquement le BOParty_Type. Ne s’agit-il pas plutôt de “PALegal_Type” où il

faut mettre 6 comme valeur ?

4. Il faut renseigner 25 euro (brut).

5. Lorsque des revenus d'origine étrangère sont payés en Belgique et qu'un

impôt étranger a été retenu sur ces revenus, il y a lieu de déduire cet impôt

étranger du montant à communiquer.

6. Il convient de rapporter dans la devise des intérêts perçus.

7. Il convient de distinguer le dernier coupon, qui correspond ici au paiement

d’un intérêt entre 2 échéances (PayementType A), de l’élément « plus-value »

(PayementType B). Pour ce dernier, la directive donne le choix aux Etats

membres entre la communication soit du montant total du remboursement soit

de la plus-value (différence entre remboursement et valeur initiale : 3.000 euro

dans l’exemple ci-contre).

8. Il est clair que les agents payeurs belges ne sont pas obligés de considérer un

décès comme un paiement d'intérêt au sens de la directive épargne.

9. PaymentQlf doit toujours = “gip”


Statut : Approuvé


van bruto min buitenlandse taks?

Vraag 6:

Bij een obligatie in vreemde munt die wordt uitbetaald in

vreemde munt diet men het bedrag in vreemde munt aan te

geven met vermelding van devies. Maar voor een obligatie

in vreemde munt, die rente betaald in vreemde munt, en

voor de klant wordt omgezet naar een betaling op zijn euro

rekening dient men dan het rente bedrag in euro of in

devies aan te geven?

Vraag 7:

Indien men spreekt over een terugbetaling van een

obligatie. Heeft men enerzijds de laatste obligatiecoupon

die betaald (PayementType A) en anderzijds heeft men

mogelijk een premie indien de inschrijvingsprijs kleiner

was dan de terugbetaling. Dient men dan het percentueel

verschil aan te geven (PayementType B)? En is dit wat

men bedoelt bij een “Totaal bedrag van de opbrengst van

de overdracht” bij een PaymentType B?

Vb: Een klant, buitenlander, schrijft in voor obligatie

100.000 nominaal aan 97% en terugbetaling aan 100%.

Dient men dan de 3000 euro aan te geven als

PayementType B?

Vraag 8:

Wat dient er te gebeuren bij een nalatenschap? Tijdens

een periode heeft men een rekening met titularisen die na

afwerking van de successierechten over een deel van de

10. Il faut prendre en considération la date de début de la relation contractuelle.


Statut : Approuvé


erfenis zullen beschikken. Mogelijk is er een der

erfgenamen onderhevig aan woornstaatheffing. Heeft de

datum van overlijden enige invloed in deze

veronderstelling?

Vraag 9:

Bij paymentQlf_Type spreekt men over gip, nip, twth en

trt. Bestaat er ergens een duidelijke omschrijving wat er

bedoelt wordt met deze termen? Of bestaat er ergens een

voorbeeld van deze bepalingen? (misschien komt daar

meer duidelijkheid over op 7 oktober)

Vraag10:

Als men spreekt over datum opening van een rekening.

Doelt men dan echt over de datum opening rekening of, in

sommige gevallen, over de datum wanneer de eigenaar

mogelijk verhuist naar het buitenland en van dan af

onderhevig is aan woonstaatheffing? Of moment dat een

buitenlander titularis wordt van een reeds bestaande

rekening?

3

0

Als er een interestbetaling is in USD op een rekening in EURO, in welke munt moet de interest gerapporteerd worden: USD of EURO?

Il convient de rapporter dans la devise des intérêts perçus donc en USD dans ce

cas-ci.

3

1

Dear, Two question regarding the reporting on addresses: 1. Can we report about foreign addresses as follows?

Using the City tag to report the City and the Post code and

leaving the PostCode tag empty?

1. Non, il faut impérativement utiliser PostCode pour renseigner « 40006 »

dans votre cas :

< AddressStruct> < Street > VIA CARINA</Street>

<BuildingIdentifier>75</BuildingIdentifier>

< PostCode >40006< /PostCode > <City> BOLOGNE</City> < /AddressStruct>


Statut : Approuvé


urn:AddressStruct>

stf:Street>VIA CARINA 75</stf:Street>

stf:PostCode></stf:PostCode>

stf:City>I-40006 BOLOGNE</stf:City>

urn:AddressStruct>

2. If we have the following case:

De heer Dupont is een Europese ambtenaar met een wettelijk adres in Brussel en een fiscale woonplaats in Frankrijk (zoals vermeld op attest HIS 276) Hij heeft een termijnrekening bij een Belgische bank die 1.000 EUR in de loop van 2010 opbrengt.

Can you confirm the approach below?

We will use the ResCountryCode Tag to report about his Tax

Country FR, and use the Address Tag to report about his legal address?

urn:BeneficialOwner oecdLegalType="01"

contractBefore2004="true">

<urn:ResCountryCode>FR</urn:ResCountryCode>

<urn:IndivPersData>

<urn:Gender>M</urn:Gender>

<urn:BirthDate>1935-10-08</urn:BirthDate>

</urn:IndivPersData>

<urn:Name>

<urn:NameStruct>

<urn:FirstName>François</urn:FirstName>

<urn:LastName>Dupont</urn:LastName>

</urn:NameStruct>

2. L’approche est correcte.


Statut : Approuvé


</urn:Name>

<urn:Address>

<urn:CountryCode>BE</urn:CountryCode>

<urn:AddressStruct>

<stf:Street>EZELSSTRAAT 6</stf:Street>

<stf:PostCode>1000</stf:PostCode>

<stf:City>BRUSSEL</stf:City>

</urn:AddressStruct>

</urn:Address>

<urn:DocSpec>

<urn:DocTypeIndic>1</urn:DocTypeIndic>

<urn:DocRefId>BE0403201185-BO-2010-

000339</urn:DocRefId>

</urn:DocSpec>

</urn:BeneficialOwner>

3

2

Quel est la procédure actuelle à suivre pour les corrections

spontanées ?

En attendant l’implémentation des corrections spontanées de type 2 par le SPF

FINANCES en 2012, il y a lieu de procéder de la sorte :

1. Envoyer une annulation du BO concerné en indiquant son DocRefId et un

DocTypeIndic = 3,

2. Envoyer un nouveau fichier contenant les nouvelles données du BO annulé

avec un nouveau DocRefId et un DocTypeIndic = 1,

3

3

3

4

3

5

N Questions/Remarques Réponses CBC,…) Wat invullen in ... · Date impression : 17/12/2010 Page 3...

Documents

Transcript of N Questions/Remarques Réponses CBC,…) Wat invullen in ... · Date impression : 17/12/2010 Page 3...