N ° Questions/Remarques Réponses 1 Hoeveel files moeten we

Transcription

N ° Questions/Remarques Réponses 1 Hoeveel files moeten we
N
Questions/Remarques
°
1 Hoeveel files moeten we aanmaken ?
- 1 per paying agent (dus 1 KBC, 1 CBC en 1 Centea) ?
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 ?
3 Moeten we antwoord op vraag correcties automatiseren
?
En zo ja, hoe zit het met weigering van deze aanvragen ?
4
Structuur DOCrefID
Welke aanduiding voor Residuele entiteit gebruiken : RE ?
Réponses
C’est bien évidemment ce qui est demandé. Un fichier par agent payeur (KBC,
CBC,…)
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.
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.
Cas : code
Agent Payeur :
PA
Identifiant
[BE][XXXXXXXXXX][-PA-]
[YYYY]-[NNNNNN]
Long
27
Exemple
BE0403201185-PA2011-000001
Bénéficiaire
effectif : BO
Entité
résiduelle : RE
Paiement : Art9
[BE][XXXXXXXXXX][-BO-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-RE-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-ART9-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-ART4.2-]
[YYYY]-[NNNNNN]
27
BE0403201185-BO2012-000001
BE0403201185-RE2013-000001
BE0403201185-ART92015-000001
BE0403201185ART4.2-2016-000001
Paiement
Art4.2
:
27
29
31
o [XXXXXXXXXX] correspond au numéro BCE
(Banque Carrefour des Entreprises) de l’agent
Date impression : 17/12/2010
Statut : Approuvé
Page 1 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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) ?
Date impression : 17/12/2010
Statut : Approuvé
Page 2 sur 25
Contact : [email protected]
DateVersion : 20122010v3
6
7
Is 7 jaar corrigeren een verplichting ? (of wordt dit
overgelaten aan de banken zelf ?)
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 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.
La durée de 7 ans est basée sur la législation belge en la matière.
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
Date impression : 17/12/2010
Statut : Approuvé
Page 3 sur 25
Contact : [email protected]
DateVersion : 20122010v3
8
9
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 ».
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 ?
Zal in geval van vragen van de buitenlandse fiscus een
refertenummer van de fiscus zelf (buitenlandse of
Belgische) meegegeven worden ?
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.
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.
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.
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.
1
0
In de documenten Jmonnet die in februari verspreid zijn, is
er sprake van testaanleveringen. Hiervoor moeten we
MessageTypeindic op 5 zetten.
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).
De printscreens voor de upload hebben 2 knoppen :
Date impression : 17/12/2010
Statut : Approuvé
Page 4 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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.
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.
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) ?
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:
Date impression : 17/12/2010
Statut : Approuvé
Page 5 sur 25
Contact : [email protected]
DateVersion : 20122010v3
<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
residentialOrBusiness
residential
business
registeredOffice
unspecified
fiscalResidence
Description
The address is either a residential or business address
The address is residential
The address is business
The address is the registered office of the legal person
The nature of the address is not specified
The address is for fiscal purposes (this is relevant for Beneficial
Owner only)
Table 1: Allowed values of the legalAddress_Type
Date impression : 17/12/2010
Statut : Approuvé
Page 6 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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
Date impression : 17/12/2010
Statut : Approuvé
Page 7 sur 25
Contact : [email protected]
DateVersion : 20122010v3
<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
Agent Payeur :
PA
Identifiant
[BE][XXXXXXXXXX][-PA-]
[YYYY]-[NNNNNN]
Long
27
Exemple
BE0403201185-PA2011-000001
Bénéficiaire
effectif : BO
Entité
résiduelle : RE
Paiement : Art9
[BE][XXXXXXXXXX][-BO-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-RE-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-ART9-]
[YYYY]-[NNNNNN]
[BE][XXXXXXXXXX][-ART4.2-]
[YYYY]-[NNNNNN]
27
BE0403201185-BO2012-000001
BE0403201185-RE2013-000001
BE0403201185-ART92015-000001
BE0403201185ART4.2-2016-000001
Paiement
Art4.2
:
27
29
31
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,
Date impression : 17/12/2010
Statut : Approuvé
Page 8 sur 25
Contact : [email protected]
DateVersion : 20122010v3
réinitialisé chaque année,
1
4
Cfr. JMonnet februari pg. 2
Ligt er al een limiet vast wat betreft grootte orde bestand ?
1
5
1
6
Is al geweten of file in ZIP formaat moet afgestaan worden
?
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"
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 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.
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"
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.
Date impression : 17/12/2010
Statut : Approuvé
Page 9 sur 25
Contact : [email protected]
DateVersion : 20122010v3
1
7
inkomstenjaren met de nieuwe versie maken ?
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"
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.
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 ?
1
8
1ère situation
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
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).
Date impression : 17/12/2010
Statut : Approuvé
Page 10 sur 25
Contact : [email protected]
DateVersion : 20122010v3
(relatif aux « paiements d’intérêts » attribués en 2010).
Comment doit-elle procéder pour communiquer par après
cette information ?
2éme situation :
Idem situation 1.
Réponse à la question générale :
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à).
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.
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
Date impression : 17/12/2010
Statut : Approuvé
Page 11 sur 25
Contact : [email protected]
DateVersion : 20122010v3
« 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.
Date impression : 17/12/2010
Statut : Approuvé
Page 12 sur 25
Contact : [email protected]
DateVersion : 20122010v3
2
0
2
1
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 ?
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 ?
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.
Cfr. Question 13 de ce document.
L’adresse à indiquer dans l’XML est toujours l’adresse de la résidence fiscale.
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
Date impression : 17/12/2010
Statut : Approuvé
Page 13 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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 ?
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.
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 ?
2
3
Voor Residuele Entiteiten (Art.4_2) dienen we cfr. jullie
informatie in vrije text de naam van de gerechtigde (the
of the Beneficial Owner )
mee te delen.
name
Cfr. Protocole.
Le nom de l’entité résiduelle ne peut qu’être « free ».
BASE:
Date impression : 17/12/2010
Statut : Approuvé
Page 14 sur 25
Contact : [email protected]
DateVersion : 20122010v3
/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:
Date impression : 17/12/2010
Statut : Approuvé
Page 15 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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. ?
Date impression : 17/12/2010
Statut : Approuvé
Page 16 sur 25
Contact : [email protected]
DateVersion : 20122010v3
2
4
Vraag rond de paying agent bij splitsen files :
C’est l’option 1.
File 1 : - Header 1– body 1(PA1 + BO1)
File 2 : - Header 2– body 2(PA1 + BO2)
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
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.
Date impression : 17/12/2010
Statut : Approuvé
Page 17 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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.
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.
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 15-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?
Date impression : 17/12/2010
Statut : Approuvé
Page 18 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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 ?
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. 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.
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
Date impression : 17/12/2010
Statut : Approuvé
Page 19 sur 25
Contact : [email protected]
DateVersion : 20122010v3
gewoon via naam, voornaam, geboortedatum,
geboorteplaats, ...?
2
8
impérativement à mentionner en plus.
3) Op basis van welke criteria moeten
interesttransacties gegroepeerd worden
vooraleer ze worden doorgestuurd naar Minfin.
zelfde persoon, type contract, munt,
fiscale woonplaats, ...
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
3. Il faut regrouper par Personne, Type de contrat, Type de compte, Devise et
adresse fiscale
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.
hebben we de keuze in de gegevensuitwisseling
om plaatsing 1 en 2 apart te rapporteren of te
globaliseren?
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)
Date impression : 17/12/2010
Statut : Approuvé
Page 20 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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”
Date impression : 17/12/2010
Statut : Approuvé
Page 21 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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?
10. Il faut prendre en considération la date de début de la relation contractuelle.
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
Date impression : 17/12/2010
Statut : Approuvé
Page 22 sur 25
Contact : [email protected]
DateVersion : 20122010v3
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
3
1
Als er een interestbetaling is in USD op een
rekening in EURO, in welke munt moet de
interest gerapporteerd worden: USD of EURO?
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?
Il convient de rapporter dans la devise des intérêts perçus donc en USD dans ce
cas-ci.
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>
Date impression : 17/12/2010
Statut : Approuvé
Page 23 sur 25
Contact : [email protected]
DateVersion : 20122010v3
urn:AddressStruct>
stf:Street>VIA CARINA 75</stf:Street>
stf:PostCode></stf:PostCode>
stf:City>I-40006 BOLOGNE</stf:City>
urn:AddressStruct>
2. L’approche est correcte.
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>
Date impression : 17/12/2010
Statut : Approuvé
Page 24 sur 25
Contact : [email protected]
DateVersion : 20122010v3
</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-2010000339</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
Date impression : 17/12/2010
Statut : Approuvé
Page 25 sur 25
Contact : [email protected]
DateVersion : 20122010v3

Documents pareils