0 Description du document
 0.1 Statut du document
 0.2 Autres documents disponibles

0 Document description
 0.1 Document status
 0.2 Other documents available

1 Principes généraux
 1.1 Contexte
 1.2 Objectifs
 1.3 Démarche

1 General principles
 1.1 Context
 1.2 Objectives
 1.3 Approach

2 Choix effectués
 2.1 Choix fonctionnels
 2.2 Choix techniques
 2.3 Terminologie utilisée dans la description des données
 2.4 Convention générale pour les flux financiers et l’application des signes
 2.5 Convention générale de datation des données

2 Choices made
 2.1 Functional choices
 2.2 Technical choices
 2.3 Terminology used in data description
 2.4 General convention on financial flows and amounts signs  
 2.5 General convention for dating data

3 Entités 
 3.0 Architecture du modèle 3.0
 Diagramme des entités FIDJI

 3.1 Entités Standard
 3.2 Entités Génériques
 3.3 Entités Anonymes

3 Entities 
 3.0 Architecture of FIDJI model 3.0
 FIDJI entities diagram

 3.1 Standard entities
 3.2 Generic entities
 3.3 Anonymous entities

4 Types de donnée et énumerations
 4.1 Types de donnée
 4.2 Enumérations
 4.3 Groupes d’attributs

5 Exemples pratiques
 5.1 Description d’un bien
 5.2 Exemple de revenus des biens (entité CALCUNIT)
 5.3 Exemple de charges et travaux (entité CALCUNIT)
 5.4 Exemple de PLAN DE COMPTE et d'ECRITURES COMPTABLES
 5.5 Exemple d'ARBORESCENCE BUDGETAIRE

4 Types of data and enumerations
 4.1 Data types
 4.2 Enumerations
 4.3 Groups of attributes

5 Practical examples
 5.1 Description of an Asset / Property
 5.2 Rent invoicing example(CALCUNIT Entity)
 5.3 Example of expenses and works (CALCUNIT Entity)
 5.4 CHART OF ACCOUNTS and ACCOUNTING ENTRIES example
 5.5 BUDGET TREE example

3 DETAIL DES ENTITES

3 ENTITIES DETAILS

3.0 Architecture du modèle 3.0

3.1 Entités Standard
 3.1.1 Entité RACINE [FIDJI]
 3.1.2 Entité LISTE D'EXPERTISES [APP.list]
 3.1.3 Entité EXPERTISE [APP]
 3.1.4 Entité LISTE DE BIENS [AST.list]
 3.1.5 Entité BIEN (référence) [ASTreference]
 3.1.6 Entité BIEN [AST]
 3.1.7 Entité LISTE DE SINISTRES [DIS.list]
 3.1.8 Entité SINISTRE [DIS]
 3.1.9 Entité LISTE D'AVENANTS [END.list]
 3.1.10 Entité AVENANT [END]
 3.1.11 Entité LISTE D'EVALUATIONS [EVA.list]
 3.1.12 Entité EVALUATION (référence) [EVAreference]
 3.1.13 Entité EVALUATION [EVA]
 3.1.14 Entité LISTE DE CAUTIONS [GUA.list]
 3.1.15 Entité CAUTION [GUA]
 3.1.16 Entité LISTE DES IMMOBILISATIONS [IMM.list]
 3.1.17 Entité IMMOBILISATION [IMM]
 3.1.18 Entité LISTE DE FACTURES [INV.list]
 3.1.19 Entité élément FACTURE (référence) [INVreference]
 3.1.20 Entité FACTURE [INV]
 3.1.21 Entité LISTE DE BAUX [LEA.list]
 3.1.22 Entité élément BAIL (référence) [LEAreference]
 3.1.23 Entité BAIL [LEA]
 3.1.24 Entité LISTE DE CREDITS-BAIL [LEC.list]
 3.1.25 Entité CREDIT-BAIL [LEC]
 3.1.26 Entité LISTE DE REGLEMENTS [PAY.list]
 3.1.27 Entité élément REGLEMENT (référence) [PAYreference]
 3.1.28 Entité REGLEMENT [PAY]
 3.1.29 Entité LISTE DE PLUS OU MOINS VALUES FINANCIERES [PMV.list]
 3.1.30 Entité PLUS OU MOINS VALUE FINANCIERE [PMV]
 3.1.31 Entité LISTE DE LOTS [PRT.list]
 3.1.32 Entité LOT (reference) [PRTreference]
 3.1.33 Entité LOT [PRT]
 3.1.34 Entité LISTE DE VALORISATIONS [VAL.list]
 3.1.35 Entité VALORISATION [VAL] 
 3.1.36 Entité LISTE DE PLANS DE COMPTES [ACC.List]
 3.1.37 Entité PLAN DE COMPTE [ACC]

3.0 Architecture of FIDJI model 3.0

3.1 Standard Entities
 3.1.1 ROOT entity [FIDJI]
 3.1.2 LIST OF VALUATIONS entity [APP.list]
 3.1.3 VALUATION entity [APP]
 3.1.4 LIST OF PROPERTIES entity [AST.list]
 3.1.5 PROPERTY (reference) entity [ASTreference]
 3.1.6 PROPERTY entity [AST]
 3.1.7 LIST OF DAMAGES entity [DIS.list]
 3.1.8 DAMAGE entity [DIS]
 3.1.9 LIST OF AMENDMENTS entity [END.list]
 3.1.10 AMENDMENTS entity [END]
 3.1.11 LIST OF EVALUATIONS entity [EVA.list]
 3.1.12 EVALUATION (reference) entity [EVAreference]
 3.1.13 EVALUATION entity [EVA]
 3.1.14 LIST OF GUARANTEES entity [GUA.list]
 3.1.15 GUARANTY entity [GUA]
 3.1.16 LIST OF CAPITALISED ASSETS entity [IMM.list]
 3.1.17 CAPITALISED ASSET entity [IMM]
 3.1.18 LIST OF INVOICES entity [INV.list]
 3.1.19 INVOICE (reference) element entity[INVreference]
 3.1.20 INVOICE entity [INV]
 3.1.21 LIST OF LEASES entity [LEA.list]
 3.1.22 LEASE (reference) element entity [LEAreference]
 3.1.23 LEASE entity [LEA]
 3.1.24 LIST OF LEASING AGREEMENTS entity [LEC.list]
 3.1.25 LEASING entity [LEC]
 3.1.26 LIST OF PAYMENTS entity [PAY.list]
 3.1.27 PAYMENT (reference) element entity [PAYreference]
 3.1.28 PAYMENT entity [PAY]
 3.1.29 LIST OF FINANCIAL GAINS OR LOSSES entity [PMV.list]
 3.1.30 FINANCIAL GAIN OR LOSS entity [PMV]
 3.1.31 LIST OF UNITS entity [PRT.list]
 3.1.32 UNIT (reference) entity [PRTreference]
 3.1.33 UNIT entity [PRT]
 3.1.34 LIST OF APPRAISALS entity [VAL.list]
 3.1.35 APPRAISAL entity [VAL] 
 3.1.36 LIST OF CHARTS OF ACCOUNTS entity [ACC.List]
 3.1.37 CHART OF ACCOUNT entity [ACC]

3.2 Entités génériques
 3.2.1 Entité LISTE D'ADRESSES [gAD.list]
 3.2.2 Entité ADRESSE [gADreference]
 3.2.3 Entité ADRESSE [gAD]
 3.2.4 Entité LISTE DE PIECES JOINTES [gAT.list]
 3.2.5 Entité PIECE JOINTE [gAT]
 3.2.6 Entité LISTE DE R.I.B. [gBA.list]
 3.2.7 Entité RIB [gBA]
 3.2.8 Entité LISTE DE CALCUNITS [gCU.list]
 3.2.9 Entité CALCUNIT [gCU]
 3.2.10 Entité LISTE DE FINANCEMENTS [gFI.list]
 3.2.11 Entité FINANCEMENT [gFI]
 3.2.12 Entité LISTE DE TIERS [gPE.list]
 3.2.13 Entité TIERS (référence) [gPEreference]
 3.2.14 Entité TIERS [gPE]
 3.2.15 Entité LISTE DE TAUX [gRA.list]
 3.2.16 Entité TAUX [gRA]
 3.2.17 Entité DETENTIONS [gHO] 
 3.2.18 Entité LISTE D'ARBORESCENCES BUDGETAIRES [gBT.list] 
 3.2.19 Entité ARBORESCENCE BUDGETAIRE [gBT] 

3.2 Generic entities
 3.2.1 LIST OF ADDRESSES entity [gAD.list]
 3.2.2 ADDRESS (reference) entity [gADreference]
 3.2.3 ADDRESS entity [gAD]
 3.2.4 LIST OF ATTACHMENTS entity [gAT.list]
 3.2.5 ATTACHMENT entity [gAT]
 3.2.6 LIST OF BANK ACCOUNT DETAILS entity [gBA.list]
 3.2.7 BANK ACCOUNT DETAIL entity [gBA]
 3.2.8 LIST OF CALCUNITS entity [gCU.list]
 3.2.9 CALCUNIT entity [gCU]
 3.2.10 LIST OF FINANCING OPTIONS entity [gFI.list]
 3.2.11 FINANCING entity [gFI]
 3.2.12 LIST OF THIRD PARTIES entity [gPE.list]
 3.2.13 THIRD PARTY (reference) entity [gPEreference]
 3.2.14 THIRD PARTY entity [gPE]
 3.2.15 LIST OF RATES entity [gRA.list]
 3.2.16 RATE entity [gRA]
 3.2.17 OWNERSHIP entity [gHO] 
 3.2.18 LIST OF BUDGET TREES entity [gBT.list] 
 3.2.19 BUDGET TREE entity [gBT]

 3.3 Entités anonymes
 3.3.1 Entité EVALUATION DE LA VALEUR DES PARTS D’UN PROPRIETAIRE [aOP]
 3.3.2 Entité REFERENCE DE MARCHES [aMR]
 3.3.3 Entité DOCUMENT [aDO]
 3.3.4 Entité EVALUATION PAR COMPOSANT IFRS [aCM]
 3.3.5 Entité PARAMETRES DE CALCUL DU DETAIL DE L’EXPERTISE [aAC]
 3.3.6 Entité DETAIL DE L'EXPERTISE [aAL]
 3.3.7 Entité COMPOSANT IFRS(référence) [aOCreference]
 3.3.8 Entité COMPOSANT IFRS [aOC]
 3.3.9 Entité UTILISATION DU BIEN [aUS]
 3.3.10 Entité INTERVENANT [aPT]
 3.3.11 Entité PROPERTY MANAGEMENT [aPM]
 3.3.12 Entité PARAMETRES DCF [aDP]
 3.3.13 Entité LIGNES DE FACTURE (référence) [aILreference]
 3.3.14 Entité LIGNES DE FACTURE [aIL]
 3.3.15 Entité DATES DE RISQUES [aRI]
 3.3.16 Entité LOTS DU BAIL [aLP]
 3.3.17 Entité DEPOTS DE GARANTIE [aCA]
 3.3.18 Entité MONTANT ET TAUX [aAM]
 3.3.19 Entité LOYERS VARIABLES [aVR]
 3.3.20 Entité AVENANTS [aEN]
 3.3.21 Entité CHARGES REFACTUREES [aRE]
 3.3.22 Entité INFORMATION PROPERTY MANAGEMENT [aRP]
 3.3.23 Entité LIGNES DE REGLEMENT [aPL]
 3.3.24 Entité TANTIEMES [aPE]
 3.3.25 Entité RATIOS [aRA]
 3.3.26 Entité PARAMETRES DE CALCUL de CALCUNIT [aCP]
 3.3.27 Entité DONNEES RESULTANTES [aRD]
 3.3.28 Entité IMMOBILISATION PAR COMPOSANT IFRS [aIC]
 3.3.29 Entité LISTE D'ECRITURES [aAE.list] 
 3.3.30 Entité ECRITURES [aAE] 
 3.3.31 Entité LISTE DE LIGNES BUDGETAIRES [aBL.list]
 3.3.32 Entité LIGNES BUDGETAIRES [aBL]
 3.3.33 Entité DEVELOPPEMENT DURABLE [aDD] 
 3.3.34 Entité LISTE DE CERTIFICATIONS [aCE.list] 
 3.3.35 Entité CERTIFICATIONS [aCE]
 3.3.36 Entité LISTE DE SURFACES [aSF.list] 
 3.3.37 Entité SURFACES [aSF] 

3.3 Anonymous entities
 3.3.1 ASSESSMENT VALUE OF THE OWNER'S SHARES entity [aOP]
 3.3.2 MARKET REFERENCE entity [aMR]
 3.3.3 DOCUMENT entity [aDO]
 3.3.4 EVALUATION BY IFRS COMPONENT entity [aCM]
 3.3.5 VALUATION DETAILS CALCULATION PARAMETERS entity [aAC]
 3.3.6 VALUATION DETAILS entity [aAL]
 3.3.7 IFRS COMPONENT (reference) entity[aOCreference]
 3.3.8 IFRS COMPONENT entity [aOC]
 3.3.9 USE OF THE PROPERTY entity [aUS]
 3.3.10 STAKEHOLDER entity [aPT]
 3.3.11 PROPERTY MANAGEMENT entity [aPM]
 3.3.12 DCF PARAMETERS entity [aDP]
 3.3.13 INVOICE LIGNES (reference) entity [aILreference]
 3.3.14 INVOICE LINES entity [aIL]
 3.3.15 RISK DATES entity [aRI]
 3.3.16 LEASE UNITS entity [aLP]
 3.3.17 SECURITY DEPOSITS entity [aCA]
 3.3.18 AMOUNT AND RATE entity [aAM]
 3.3.19 VARIABLE RENTS entity [aVR]
 3.3.20 AMENDMENTS entity [aEN]
 3.3.21 RE-INVOICED EXPENSES entity [aRE]
 3.3.22 PROPERTY MANAGEMENT INFORMATION entity [aRP]
 3.3.23 PAYMENT LINES entity [aPL]
 3.3.24 APPORTIONMENT RATE entity [aPE]
 3.3.25 RATIOS entity [aRA]
 3.3.26 CALCULATION PARAMETERS of CALCUNIT entity [aCP]
 3.3.27 RESULTING DATA entity [aRD]
 3.3.28 CAPITALISED ASSET BY IFRS COMPONENT entity [aIC]
 3.3.29 LIST OF ACCOUNTING ENTRIES entity [aAE.list] 
 3.3.30 ACCOUNTING ENTRIES entity [aAE] 
 3.3.31 LIST OF BUDGET LINES entity [aBL.list]
 3.3.32 BUDGET LINES entity [aBL]
 3.3.33 SUSTAINABLE DEVELOPMENT entity [aDD] 
 3.3.34 LIST OF CERTIFICATIONS entity [aCE.list] 
 3.3.35 CERTIFICATION entity [aCE]
 3.3.36 LIST OF SURFACE AREAS entity [aSF.list] 
 3.3.37 SURFACE AREA entity [aSF]

4 Types de données et énumérations (liste de valeurs)

4 Data Types and enumerations (list of values)

4.1 Types de données
 4.1.1 gtNonGere
 4.1.2 gtFlag
 4.1.3 gtBlob
 4.1.4 gtAlphaNum
 4.1.5 gtAlphaNum11
 4.1.6 gtAlphaNum40
 4.1.7 gtAlphaNum50
 4.1.8 gtAlphaNum100
 4.1.9 gtSignedUShort
 4.1.10 gtUShort
 4.1.11 gtUInteger
 4.1.12 gtULong
 4.1.13 gtDecimal
 4.1.14 gtDate
 4.1.15 gtDateTime
 4.1.16 gtYear
 4.1.17 gtDigits
 4.1.18 gtDigits2
 4.1.19 gtDigits5
 4.1.20 gtDigits11
 4.1.21 gtTransco
 4.1.22 gtRate
 4.1.23 gtMoney
 4.1.24 gtDigits4
 4.1.25 gtDigits14
 4.1.26 gtAlphaNum2
 4.1.27 gtAlphaNum12
 4.1.28 gtAlphaNum30

4.1 Data types
 4.1.1 gtNonGere
 4.1.2 gtFlag
 4.1.3 gtBlob
 4.1.4 gtAlphaNum
 4.1.5 gtAlphaNum11
 4.1.6 gtAlphaNum40
 4.1.7 gtAlphaNum50
 4.1.8 gtAlphaNum100
 4.1.9 gtSignedUShort
 4.1.10 gtUShort
 4.1.11 gtUInteger
 4.1.12 gtULong
 4.1.13 gtDecimal
 4.1.14 gtDate
 4.1.15 gtDateTime
 4.1.16 gtYear
 4.1.17 gtDigits
 4.1.18 gtDigits2
 4.1.19 gtDigits5
 4.1.20 gtDigits11
 4.1.21 gtTransco
 4.1.22 gtRate
 4.1.23 gtMoney
 4.1.24 gtDigits4
 4.1.25 gtDigits14
 4.1.26 gtAlphaNum2
 4.1.27 gtAlphaNum12
 4.1.28 gtAlphaNum30

4.2 Enumerations
 4.2.1 geTypeInvestisseur
 4.2.2 geRegimeFiscalAcquisition
 4.2.3 geTypeUnitesSecondaires
 4.2.4 gePeriodicity
 4.2.5 geCurrency
 4.2.6 geTypeConge
 4.2.7 geTypeSurface
 4.2.8 geNatureOccupation
 4.2.9 geTypeMethode
 4.2.10 geTypeValorisationVacant
 4.2.11 geFormeDetention
 4.2.12 geTypeBail
 4.2.13 geUsagePrincipal
 4.2.14 geUtilisationPrincipale
 4.2.15 geLocalisation
 4.2.16 geQualite
 4.2.17 geStrategieGestion
 4.2.18 geTypeInterv
 4.2.19 geTypeMouvement
 4.2.20 geTypeExpertise
 4.2.21 geTypeValeurExpertise
 4.2.22 geTypeVisite
 4.2.23 geTypeDocument
 4.2.24 geStatutDemande
 4.2.25 geStatutReception
 4.2.26 geTypeLot
 4.2.27 geFermetureParking
 4.2.28 geTransmission
 4.2.29 geTypeIndice
 4.2.30 geTypePMV
 4.2.31 geModeRefacturation
 4.2.32 geTypeLocation
 4.2.33 geCodeRubrique
 4.2.34 geTypeActif
 4.2.35 geRegTVA
 4.2.36 geTypeAdresse
 4.2.37 geNatRisque
 4.2.38 geTypeCaution
 4.2.39 geTypeRevenus
 4.2.40 geRegionAdm
 4.2.41 geModeReglement
 4.2.42 geActivite
 4.2.43 geRoleTiers
 4.2.44 geTypeFacture
 4.2.45 geNatureCharge
 4.2.46 geCodeOperation
 4.2.47 geCivilite
 4.2.48 geMethodeCalcul
 4.2.49 geTypePlafond
 4.2.50 geTypePlancher 
 4.2.51 geTypeAuxiliaire
 4.2.52 geTypeEcriture
 4.2.53 geNiveauCertif
 4.2.54 geLabelEnergie
 4.2.55 geFlag3Valeurs
 4.2.56 geTypeCertif

4.2 Enumerations
 4.2.1 geInvestorType
 4.2.2 geAcquisitionTaxation
 4.2.3 geSecondaryUnitsType
 4.2.4 gePeriodicity
 4.2.5 geCurrency
 4.2.6 geNoticeType
 4.2.7 geSurfaceType
 4.2.8 geOccupancyNature
 4.2.9 geMethodType
 4.2.10 geVacantAppraisalType
 4.2.11 geOwnershipForm
 4.2.12 geLeaseType
 4.2.13 gePrimaryUsage
 4.2.14 gePrimaryUse
 4.2.15 geLocation
 4.2.16 geQuality
 4.2.17 geManagmentStrategy
 4.2.18 geStakehType
 4.2.19 geMovementType
 4.2.20 geValuationType
 4.2.21 geAppraisedValueType
 4.2.22 geVisitType
 4.2.23 geDocumentType
 4.2.24 geRequestStatus
 4.2.25 geReceptionStatus
 4.2.26 geUnitType
 4.2.27 geCarParkClosing
 4.2.28 geTransmission
 4.2.29 geIndexType
 4.2.30 geGainLossType
 4.2.31 geReinvoicingMethod
 4.2.32 geRentalType
 4.2.33 geSectionCode
 4.2.34 geAssetType
 4.2.35 geVATArr
 4.2.36 geAddressType
 4.2.37 geRiskNature
 4.2.38 geGuaranteeType
 4.2.39 geIncomeType
 4.2.40 geAdmRegion
 4.2.41 gePaymentMethod
 4.2.42 geActivity
 4.2.43 geThirdPartyRole
 4.2.44 geInvoiceType 
 4.2.45 geExpenseNature
 4.2.46 geOperationCode
 4.2.47 geTitle
 4.2.48 geCalculationMethod
 4.2.49 geTypeCappedRent
 4.2.50 geTypeLowerRent 
 4.2.51 geAuxiliaryType
 4.2.52 geEntryType
 4.2.53 geLevelCertif
 4.2.54 geLabelEnergy
 4.2.55 geFlag3Values
 4.2.56 geTypeCertif

4.3 Groupes d’attributs
 4.3.1 gagCommonAttributeGroup

4.3 Groups of attributes
 4.3.1 gagCommonAttributeGroup

5 Exemples pratiques

5 Practical examples

5.1 Description d'un BIEN

5.1 PROPERTY Description

5.2 Exemple de facturation du loyer (entité CALCUNIT)

5.2 Rent invoicing example (CALCUNIT entity)

5.3 Exemple de charges et travaux (entité CALCUNIT)
 5.3.1 Charges réalisées
 5.3.2 Travaux réalisés
 5.3.3 Charges prévisionnelles

5.3 Service charges and works example (CALCUNIT entity)
 5.3.1 Service charges made
 5.3.2 Works completed
 5.3.3 Forecast service charges

5.4 Exemple de PLAN DE COMPTE et d'ECRITURES COMPTABLES
5.5 Exemple d'ARBORESCENCE BUDGETAIRE

5.4 CHART OF ACCOUNT and ACCOUNTING ENTRIES example
5.5 BUDGET TREE example

0.1 Statut du document

0.1 Document status

Ce document décrit le format FIDJI 3.0 (Documentation technique). 

Le contenu de cette version a été mis à jour le 15 juin 2015 pour mise à disposition de la version 3.0 du modèle

Copyright (c) 2015

This document describes the FIDJI 3.0 format (Technical documentation). 

The content of this version was updated on June 15, 2015 for the release of version 3.0 of the model.

Copyright (c) 2015

0.2 Autres documents disponibles

0.2 Other documents avalaible

Cette documentation en ligne est complétée par le Descriptif Général du modèle FIDJI 3.0, téléchargeable au format pdf, ainsi que par le fichier XSD de validation de contenu XML disponible sur le site de l'Association. 

Par ailleurs, les adhérents à l'Association FIDJI peuvent disposer d'un document dénommé Dictionnaire FIDJI au format Excel décrivant de manière détaillée le contenu du format, ainsi que du kit de certification pour la version 3.0. 

Les adhérents de l'Association FIDJI peuvent bénéficier du support technique de l'association et ont à disposition un Viewer qui leur permet d'effectuer le contrôle de conformité des fichiers FIDJI générés avec les données utilisateurs, ainsi que de visualiser leur contenu avec la traduction des codifications.

This online documentation is supplemented by the Summary of the model FIDJI 3.0, downloadable in pdf format, and by the XSD file for XML content validation available on the Association’s website.

In addition, members of the FIDJI Association have access to a document in Excel format referred to as the Dictionary FIDJI, describing in detail the contents of the format, as well as the certification kit for version 3.0.

FIDJI Association members can benefit from the association's technical support and have access to a Viewer that allows them to check the conformity of the generated FIDJI files with the user data and to visualize their content with the translation of the codifications.

 1.1 Contexte

 1.1 Context

Suite à une importante augmentation des échanges de données dans la profession immobilière, nous observons :

·       Un recours plus large à la délégation de gestion,

·       Une rotation accrue des portefeuilles,

·       Une multiplication des expertises,

·       Une forte demande d’évaluation de performance de la part des investisseurs (ex : benchmarking MSCI).

Ces échanges de données mobilisent des ressources importantes à tous les stades de leur mise en œuvre :

·       Extraction du système source,

·       Retraitement (agrégation, recomposition…),

·       Transcodification (réalisée soit lors de l’extraction, pour produire des identifiants compatibles avec le système cible, soit lors de l’intégration dans le système cible),

·       Intégration.

As a result of a major increase in data exchange in the real estate industry, we have been witnessing:

·       a wider use of delegated management,

·       an increased portfolio turnover,

·       a multiplication of the number of valuations,

·       a strong demand for performance evaluation (e.g. MSCI benchmarking) from investors.

These data exchanges summon up significant resources at all stages of their implementation:

·       Extraction from the source system,

·       Reprocessing (aggregation, recombination, etc.),

·       Transcoding (performed either during the extraction, to produce identifiers compatible with the target system, or during the integration into the target system),

·       Integration.

En particulier, l’arrivée des OPCI implique une forte mécanisation de l’échange d’information entre les experts immobiliers et les sociétés de gestion. A ce jour, les investisseurs transmettent, dans des formats qui leur sont propres (fichiers Excel, base Access, Extranet, documents papiers…), des données immobilières à leurs experts qui doivent alors les retraiter pour les insérer dans leurs systèmes de valorisation.

En retour, les experts produisent également de l’information que les investisseurs doivent ré-insérer dans leurs systèmes de gestion.

Ces échanges de données et multiples retraitements sont lourds et consommateurs de ressources importantes, et non-dénués de risques d’erreur à tous les stades de leur mise en oeuvre.

L’idée est donc née de mettre en place un format standard de fichier d’inter-échanges d’information immobilière sur lequel s’entendrait la profession.

In particular, the emergence of OPCIs (collective real estate investment schemes) requires automating information exchanges between real estate experts and management companies. To date, investors transmit, in formats that are specific to them (Excel files, Access database, Extranet, paper documents...), real estate data to their experts who must then reprocess this data to insert it into their appraisal systems.

In return, valuers also produce information that the investors must re-integrate into their management systems.

These multiple processing operations are tedious, resource-intensive, and not without risks of error at all stages of their implementation.

This gave rise to the idea of implementing a standard property data interchange format for adoption by the whole industry.

 1.2 Objectifs

 1.2 Objectives

Afin de répondre aux problématiques rappelées ci-dessus, les bénéfices de la mise en place d’un format standard permettant d’échanger des informations immobilières sont multiples.

Les objectifs recherchés dans la mise en place de cette norme d’inter-échanges sont les suivants :

·       Adopter des définitions communes (langage commun) sur les données échangées

·       Accélérer les processus d’échange

·       Eviter les ressaisies d’information

·       Limiter les retraitements informatiques « à façon »

·       Fiabiliser les données transmises (contrôles intégrés au format)

·       Disposer d’un format unique pour l’ensemble de la profession (richesse du contenu fonctionnel)

Le processus d'acquisition de données par l'investisseur / Asset Manager est essentiellement le résultat des flux d'information communiqués par ses Property Managers. L'objectif est multiple pour l'investisseur : consolidation des portefeuilles en gestion déléguée chez différents Property, reporting sur la gestion de ces biens, communication d'informations pour expertise, benchmarking MSCI, données transmises au dépositaire.

Dans le cadre de la relation entre l’investisseur/propriétaire et l’expert, la mécanique mise en œuvre sera la suivante :

·       L’investisseur produit, à partir de ses systèmes, un fichier contenant l’ensemble des données nécessaires à l’expertise,

·       L’expert récupère ces données, produit sa valorisation et génère un nouveau fichier, contenant cette fois les paramètres et les résultats de l’expertise,

·       L’investisseur intègre ce fichier dans son système. D’éventuels allers-retours sont possibles si des mises à jour interviennent dans les données immobilières ou dans l’expertise.

In order to answer the above-mentioned issues, there are many benefits to implementing a standard format for exchanging real estate data.

The goals in implementing this interchange standard are as follows:

·       Adopt common definitions (common language) for exchanged data

·       Speed up exchange processes

·       Avoid duplicate data entries

·       Limit "customised" IT reprocessing

·       Improve reliability of the data transmitted (verifications integrated into the format)

·       A single format for the entire industry (rich functional content)

The data acquisition process by the investor / Asset Manager is essentially the result of the flows of information communicated by its Property Managers. Investor's goals are many: consolidation of delegated management portfolios to different Property Managers, reporting on the management of these assets, providing information for expertise, MSCI benchmarking, data transmitted to the depositary.

As part of the relationship between the investor/owner and the expert/valuer, the following process will be implemented:

·       Using their systems, the investor produces a file containing all the data required for the valuation,

·       The valuer retrieves this data, produces an appraisal and generates a new file containing the valuation parameters and results,

·       The investor integrates this file into their system. Back-and-forth exchanges are possible should the property data or valuation be updated.

Dans un cadre plus large, un investisseur souhaitant céder un actif ou un portefeuille pourra produire un « fichier immeuble » complet et le mettre à disposition des acquéreurs. Lors de la cession de l’actif ou du portefeuille, l’ensemble des données comptables, techniques et locatives pourra être transmis au nouveau propriétaire pour accélérer sa prise en main de l’actif.

Dans le même ordre d’idées, les fichiers ainsi produits seront directement exploitables par les dépositaires pour la communication des actifs OPCI et par MSCI dans le cadre du benchmarking investisseurs.

Enfin, la solution choisie devra être évolutive : les types de fichiers produits seront marqués d’un numéro de version de la norme, et cette norme évoluera dans le temps afin d’élargir son spectre et de prendre en compte une plus grande richesse d’informations transmises au fur et à mesure que les besoins évolueront.

As part of a broader context, an investor wishing to sell an asset or portfolio will be able to produce a comprehensive "building file" and make it available to the buyers. During transfer of the asset or portfolio, all accounting, technical and rental data may be transmitted to the new owner to speed up their takeover of the asset.

Similarly, the files produced may be used directly by the depository authorities for communicating OPCI assets and by MSCI as part of the investor benchmarking process.

Finally, the solution selected must be upgradable: the types of files produced will feature the version number of the standard and this standard will be upgraded over time to broaden its spectrum and take into account a greater range of transmitted information as needs evolve.

 1.3 Démarche

 1.3 Approach

Lors du lancement du projet, un tour d’horizon des différents acteurs du marché nous a conduits à obtenir un accord de principe sur la mise en place de ce format.

Il est clairement entendu que le format sera totalement libre. Ses spécifications seront diffusées sur le site Internet de l'Association FIDJI de sorte que l’ensemble des acteurs et des éditeurs informatiques pourra l’adopter.

L'Association FIDJI se positionne en architecte technique de la solution et propose de centraliser l’information afin de produire d’une part les spécifications fonctionnelles et techniques et d’autre part les premiers jeux d’essais sur la base de ce format avec ses partenaires contributeurs tels que l'ont été à la première heure Altus-Taliance, MSCI, Icade Expertise, CBRE Valuation, Crédit Agricole Immobilier, La Française AM, Générali. Les clients des éditeurs informatiques adhérents et certifiés par l’association FIDJI bénéficieront de fait de la garantie que les fichiers exportés répondent à cette norme.

Les utilisateurs de solutions logicielles pourront librement utiliser ce format dès lors que leurs éditeurs ou prestataires auront intégré cette fonctionnalité et quils auront obtenu la garantie de conformité par l’association FIDJI qui leur aura délivré le certificat. Selon la politique commerciale de chaque fournisseur, le module qu’il aura développé, permettant la production du fichier FIDJI, sera inclus dans l’offre ou fera l’objet d’un droit d’usage.

En termes de planning, il est aujourd’hui prévu que les éditeurs adhérents aient intégrés les nouvelles fonctionnalités de la version 3.0 du format pour le début de l’année 2016.

Un module optionnel exclusivement réservé aux adhérents permettra temporairement aux utilisateurs de redescendre en version 2.01 les fichiers FIDJI 3.0 qu’ils recevraient, si la mise à jour de leur système n’est pas encore réalisée.

An initial review of the various market players resulted in a tentative agreement for implementing this format.

It is clearly understood that the format will be totally free. Its specifications will be available on the FIDJI Association's website, so that all IT stakeholders and vendors can adopt it.

The FIDJI Association is the technical architect of this solution and proposes centralising the information to produce the functional and technical specifications as well as the initial test cases using this format, in conjunction with its contributing partners such as long-standing partners Altus-Taliance, MSCI, Icade Expertise, CBRE Valuation, Crédit Agricole Immobilier, La Française AM, Générali. The customers of software vendors who are certified members of the FIDJI association will benefit from a guarantee that the exported files comply with this standard.
 

The users of software solutions will be free to use this format as soon as the vendors or service providers have integrated this functionality and once they have obtained the guarantee of compliance from the FIDJI association, which has issued the certificate. The module developed enabling production of the FIDJI file will be included in the offer or will be subject to a user right, depending on the business policy of each supplier.

In terms of planning, it is now expected that member publishers will have integrated the new features of the format 3.0 version by the beginning of 2016.

An optional module reserved exclusively for members will temporarily allow users to downgrade to version 2.01 the FIDJI 3.0 files they would receive, if their system has not yet been updated.

 2.1 Choix fonctionnels concernant la version 3.0

 2.1 Functional choices for release 3.0

Par rapport à la précédente version 2.01 du format, cette mise à jour du modèle FIDJI a pour objectif d'apporter davantage d'exhaustivité dans les informations communiquées par les Property Managers aux investisseurs et aux Asset managers.

La préoccupation a été d'assurer la compatibilité ascendante de cette version, dans la mesure où les données ajoutées sont optionnelles : un fichier en version 2.01 ne doit pas révéler d'erreur due à la version lorsqu'il sera contrôlé par le fichier de contrôle 3.0 (Schéma XSD de la version).

Le principal apport concerne la Comptabilité Générale avec sa relation aux comptes auxiliaires clients et fournisseurs, ainsi que le suivi budgétaire annuel des immeubles (prévisions, actualisations, réalisations).

Cette comptabilité est rattachée au Tiers Propriétaire des biens concernés. Au regard de la diversité des contextes, le groupe de projet a considéré qu'il ne pouvait y avoir de Plan de Compte de Référence dans FIDJI vers lequel ou à partir duquel chaque contributeur aurait converti son propre plan. De ce fait le format véhicule la correspondance des comptes émetteur/destinataire, ce qui implique qu'une table de correspondance soit gérée dans les modules d'export FIDJI de chaque progiciel de Property Management.

Par ailleurs, la correspondance entre les identifiants du système émetteur avec ceux du destinataire, déjà présente en version 2.01 pour les Lots et les Baux, a été également ajoutée au niveau du Bien et du Tiers.

Un volet développement durable est maintenant associé au bien. Il se rapporte aux certifications HQE, LEAD et BREEAM, à la performance énergétique et aux consommations.

Enfin, un certain nombre de point ponctuels dont les besoins ont été exprimés par les adhérents utilisateurs depuis la précédente version 2.01 ont été pris en compte et font partie de cette mise à jour.

Compared to the format previous 2.01 version, this update FIJDI model aims to provide greater completeness in the information provided by the Property Managers to the investors and asset managers.

The concern has been to ensure the backwards compatibility of this version, as the added data is optional: a version 2.01 file should not reveal any version error when checked by the 3.0 control file (XSD Schema of the version).

The main contribution concerns the General Accounting with its relationship with customers and suppliers auxiliary accounts and the annual budgetary monitoring of buildings (forecasts, updates, achievements).

Accounting is attached to the third party owner of the property. Due to the diversity of contexts, it was considered that there couldn't exist a Reference Account Plan into FIDJI. Thus, the format conveys the correspondence between sender and recipient accounts, which implies that a correspondence table is managed in the FIDJI export modules of each Property Management software package.

Furthermore, the correspondence between the identifiers of the transmitting system with those of the recipient, already present in version 2.01 for Units and Leases, has also been added for properties and third parties.

A "sustainable development" component is now associated to the property.It relates to HQE, BREEAM and LEAD certifications, energy performance and consumption.

Finally, a certain number of specific points whose needs have been expressed by user members since the previous version 2.01 have been taken into account and are part of this update.

 2.2 Choix techniques

 2.2 Technical choices

Les fichiers d’inter-échanges utiliseront le format XML. Ils respecteront par ailleurs un mode d’organisation et un ensemble de règles définis par un modèle XSD. Il s’agit de normes techniques internationales et reconnues, garantissant l’intégrité des données et l’évolutivité des fichiers.

► XML (Extented Markup Langage)

·       un langage mature

·       une adoption large

► XSD (XML Schema Definition)

·       le successeur de DTD (Document Type Definition)

·       un standard de plus en plus utilisé lorsqu’un recours aux schémas XML est nécessaire, en alternative à XDR ou XML-DRL

·       une description de schémas reconnue par la quasi-totalité des parsers XML.

·       des possibilités de contrôle étendues par rapport aux normes précédentes (format, intégrité…)

► 3 principes complémentaires ont guidé la mise en place de cette norme :

·       contrôle sur l’intégrité et le format des éléments insérés

·       souplesse sur le contenu des fichiers (éléments présents ou absents)

·       absence de codifications imposées. Le système source peut transmettre des données en utilisant :

o   ses propres codifications

o   les codifications du système cible

o   un système de codification intermédiaire mis en place entre les parties

Cette souplesse implique toutefois, pour les logiciels utilisant le format d’échanges, de gérer les transcodifications :

·       soit en sortie

·       soit en entrée

·       soit de manière mixte en entrée et sortie

Dans le cas de logiciels dialoguant avec des sources de données multiples, les transcodifications devront être stockées par source.

► Exemple :

Lors de la transmission d’un bail vers un outil d’Asset Management, le RIB du locataire ne présente aucune utilité. Ce qui n’est évidemment pas le cas lors de la reprise d’un fichier de locataire opérée lors de la cession d’un immeuble. En conséquence :

·       lorsque le RIB est inséré, il doit respecter un format très précis

·       il n’est pas obligatoire de transmettre un RIB sous un tiers locataire

Les contraintes imposées par les éditeurs de logiciels ou les organismes/partenaires destinataires des fichiers sont donc susceptibles d’être plus rigoureuses que celles figurant dans la présente norme, en fonction de l’utilisation qui doit être faite des données transmises.

The interchange files will use the XML format. They will also comply with an organisation method and a number of rules defined by an XSD model. These are recognised international technical standards that guarantee data integrity and file upgradability.

► XML (Extended Markup Language)

·       a mature language

·       widely adopted

► XSD (XML Schema Definition)

·       the successor to DTD (Document Type Definition)

·       a standard increasingly used when XML schemas are required as an alternative to XDR or XML-DRL

·       a schema description recognised by nearly all XML parsers.

·       extensive control possibilities compared with the previous standards (format, integrity, etc.)

► 3 additional principles initially guided the implementation of this standard:

·       control of the integrity and format of the integrated elements

·       flexibility on the content of the files (present or absent elements)

·       absence of imposed codifications. The source system can transmit data using:

o   its own codifications

o   the codifications of the target system

o   an intermediate codification system established between the parties

For software programmes using the exchange format, this flexibility involves management of transcodifications:

·       at the exit

·       or at the entry

·       or in a mixed entry/exit manner

In the case of software programmes interacting with multiple data sources, the transcodifications must be stored by source.

► Example:

When transmitting a lease to an asset management tool, the tenant's bank account details are irrelevant, which is obviously not the case when a tenant file is transferred during the sale of a building. Consequently:

·       when the bank account details are inserted, they must comply with a very specific format

·       It is not compulsory to transmit the bank account details of a third-party tenant.

The constraints imposed by software publishers or the organizations/partners receiving the files are therefore likely to be more strict than those set out in this standard, depending on the use to be made of the data transmitted.

 2.3 Terminologie utilisée dans la description des données

 2.3 Terminology used in data description

►Typologie des entités

Les entités « associées » à une entité principale, peuvent figurer en référence dans l’entité parente pour éviter la redondance des données, notamment lorsqu’elles sont impliquées dans plusieurs entités principales (par exemple les lots ou les tiers). Elles peuvent également être décrites entièrement dans l’arborescence lorsqu’il n’y a pas de redondance.

Les entités « inclues » sont décrites systématiquement dans l’arborescence du parent. En général, il s’agit d’entités « anonymes » qui n’ont de sens que par rapport à leur entité parente. Elles n’ont pas d’identifiant unique dans la plupart des cas ce qui fait qu’elles ne peuvent pas être seulement en référence.

Les entités « génériques » peuvent être rattachées à différentes entités parentes et leur contenu varie en fonction du contexte (L’exemple le plus rencontré concerne l’entité de Calculs CALCUNIT).

► Typologie des données élémentaires

La longueur des champs peut être explicitement spécifiée (exemple : gtAlphaNum40 et gtDigit11)
ou limitée au maximum accepté par les règles du XML.

Pour de nombreuses données, notamment alphanumériques, il est impossible d'imposer une longueur définie sachant que les progiciels émetteurs ou récepteurs ne se sont pas a priori concertés, sauf lorsqu'il y a une règle de gestion précise qui s'applique (exemple du code IBAN, du numéro SIRET, du Code actif Pseudo-ISIN).

L'échelle des données, notamment numériques, est supposée être du même ordre de grandeur.

Il est préférable que les champs alphanumériques, ne dépassent pas 100 caractères sauf les champs commentaire qui peuvent être "élastiques", au risque de ne pas être entièrement pris en compte à la réception.

► Types of entities

Entities "related" to a main entity, may be included by reference in the parent entity to avoid data redundancy, especially when they are involved in several main entities (e.g. units or third parties). They can also be described fully in the tree structure when there is no redundancy.

The "included" entities are described systematically in the tree structure of the parent. In general, these are "anonymous" entities that only make sense in relation to their parent entity. In most cases they do not have a unique identifier, which means that they cannot be addressed by reference only.

The "generic" entities can be attached to different parent entities and their contents vary depending on the context (The most common example is the CALCUNIT calculation entity).

► Typology of data items

The length of the field can be explicitly specified (eg gtAlphaNum40 and gtDigit11)

or limited to the maximum allowed by the rules of XML.

For many data, in particular alphanumeric data, it is impossible to impose a defined length knowing that the transmitting and the receiving software have not been coordinated, except when there is a precise management rule that applies (e.g. the IBAN code, the SIRET number or the active Pseudo-ISIN code).

The data scale, especially for digital data, is assumed to be of the same order of magnitude.

The alphanumeric fields will preferably not exceed 100 characters, except for the comment fields which may be "stretchable", at the risk of not being fully taken into account upon reception.

 2.4 Convention générale pour les flux financiers et l'application des signes 

 2.4 General convention on financial flows and amounts signs 

► Règle définissant la convention de signe pour les montants de tous les flux financiers véhiculés par l'entité CALCUNIT dans le modèle FIDJI afin qu’émetteur et destinataire se comprennent : un flux est signé positif si c’est un produit et un flux est signé en négatif si c’est une charge.

Cette règle est indépendante du code rubrique : en effet, au niveau du BAIL, les charges et travaux refacturés au locataire sont considérés comme des annulations de charges, donc des revenus du point de vue du Bailleur et à ce titre signés positivement. Cela n'exclue pas la possibilité de charges et travaux signés négativement lorsqu'ils sont directement imputés au BAIL.

Cette règle n'est pas applicable aux Factures et aux Règlements qui doivent être signés tels qu’ils sont présentés sur leur support d’origine et tels qu'ils seront centralisés en comptabilité générale. Le signe peut donc être inversé en cas de montant concernant par exemple une remise, un remboursement de trop perçu, une annulation d'opération, une ligne d'avoir. 

► Les montants de flux financiers ne doivent comporter que deux décimales après la virgule. 

► D’une manière générale, ils sont exprimés HORS TAXES sauf mention explicite.

► Rule defining the sign convention for the amounts of all financial flows carried by the CALCUNIT entity in the FIDJI model so that sender and recipient understand each other: a flow is signed positive if it is a product and a flow is signed negative if it is an expense.

This rule is independent of the section code: actually, at Lease level, the charges and works re-invoiced to the tenant are considered as cancellation of charges, therefore revenues from the Lessor's point of view and as such signed positively.
This does not exclude the possibility of negatively signed charges and works when these are directly charged to the LEASE.

This rule does not apply to invoices and payments that must be signed as presented on their original media and as they will be centralized in general accounting. The sign can be reversed if the amount concerns a discount, an overpayment refund, a transaction cancellation, a line of credit.

► The amounts must contain only two decimal places.

► In general, they are expressed excluding taxes unless explicitly stated.

 2.5 Convention générale de datation des données

 2.5 General convention for dating data

Les données exportées sont celles correspondant à la date de situation (1) qui figure en en-tête du fichier FIDJI.

L’étendue de l’historique et des prévisions sont des paramètres du système émetteur en fonction de conventions établies avec les destinataires, par exemple trois mois pour les experts (pour les OPCI valorisées tous les trimestres) ou selon la fréquence de transmission entre Property et Investisseur, ou une année à la date de situation (du 01/01 au 31/12).

Afin de cadrer complètement le contenu du fichier, une date de début de période des données extraite a été ajoutée dans les paramètres généraux du fichier (Entité racine).

Une date d’arrêté des écritures comptables a également été ajoutée dans les paramètres généraux du fichier. Cette date peut être différente de la date de situation de l’ensemble des autres données par exemple en fonction de la présence ou non des écritures d’inventaire dans le fichier.

Par ailleurs, le principe de FIDJI étant de transporter tout type de données sur la base d’un format unique quel que soit le destinataire, il relève donc du système émetteur de proposer un filtrage pertinent du périmètre des données communiquées en fonction du destinataire. Par exemple, l’export des écritures de comptabilité générale ou de l’historique des factures, compte-tenu de leur volumétrie potentielle, doit être une option de même que la période concernée.

The exported data corresponds to the situation date (1) contained in the header of FIDJI file.

The extent of the history and forecasts are parameters of the issuing system according to conventions established with the recipients, e.g. three months for experts (for OPCI valued every quarter) or according to the frequency of transmission between Property and Investor, or one year on the situation date (from 01/01 to 31/12).

In order to completely define the content of the file, a start date for the period of the extracted data has been added in the general parameters of the file (Root Entity).

A closing date for accounting entries has also been added to the general file parameters. This date can be different from the situation date of all the other data, e.g. depending on whether or not inventory entries are present in the file.

Moreover, as the principle of FIDJI is to transport any type of data on the basis of a single format, regardless of the recipient, it is therefore up to the transmitting system to propose a relevant filtering of the scope of the data communicated according to the recipient. For example, the export of general accounting entries or the history of invoices, given their potential volume, should be an option, as well as the period concerned.

 3.0 Architecture du modèle FIDJI 3.0

 3.0 Architecture of FIDJI model 3.0

L’architecture des versions initiales du format FIDJI prenait essentiellement en compte les biens physiques immeubles. Le développement des OPCI et des acquisitions de parts de sociétés ont conduit à considérer que le bien décrit et véhiculé par le format de données pouvait être soit physique, soit financier et que l’actif détenu n’était pas obligatoirement un immeuble.

De ce fait, depuis la version 2.0 du modèle, la notion de propriété ne constitue plus une branche de l’entité « bien immeuble », mais une relation de propriété ou de détention entre un tiers et un actif de nature immeuble ou de nature « parts détenues » d’une société.

L’entité Tiers se trouve ainsi enrichie de sous-ensembles se rapportant à la notion de détention ainsi que des éléments financiers propres au propriétaire détenteur tels que la comptabilité du portefeuille de biens dans cette version 3.0 du modèle et les Composants IFRS immobilisés.

Les entités Facture et Règlement (fournisseur ou client) ont été spécifiées dans la version 2.0 et peuvent maintenant être rattachées aux écritures comptables pour les comptes auxiliarisés.

Il est à noter que les lots ET les baux (ainsi que le lien entre les deux) seront décrits dans les données communiquées via le format FIDJI, de sorte que l’expert puisse travailler sur la base qui lui convient. 

Il faut lire dans ce schéma qu’un immeuble comporte éventuellement plusieurs baux, que chaque bail comporte éventuellement plusieurs lignes de revenus, et ainsi de suite. La « valorisation » correspond à un élément du plan de valorisation de l’investisseur/propriétaire (par exemple : « valorisation au 31.12.2006 »). Une valorisation comprendra éventuellement plusieurs expertises (celles du ou des experts).

D’autres informations pourront être adjointes ultérieurement dans le fichier, comme des documents électroniques par exemple. A partir de ces données, l’expert procède à son expertise. L’expert complètera ensuite le fichier immeuble en ajoutant son expertise au plan de valorisation.

Le modèle général de l'arborescence FIDJI complète peut être représenté, pour un immeuble dans ce diagramme général des Entités :

[En rouge les nouvelles entités de la version 3.0, en Bleu, les entités auxquelles des données ont été ajoutées].

The architecture of the initial versions of the FIDJI format essentially took into account physical immovable assets. The development of OPCIs and the acquisition of company shares led to the consideration that the asset described and conveyed by the data format could be either physical or financial and that the asset held was not necessarily real estate.

Therefore, since the 2.0 version of the model, the concept of ownership is no longer a branch of the "real property" entity, but an ownership or holding relationship between a third party and either an asset of an immovable nature or an asset of the nature of "shares held" in a company.

The Third Party entity is thus enriched with subsets relating to the notion of holding as well as financial elements specific to the owner-holder such as the accounting of the portfolio of assets in this version 3.0 of the model and the IFRS Fixed Assets Components.

The Invoice and Payment entities (supplier or customer) have been specified in version 2.0 and can now be attached to the accounting entries for auxiliary accounts.

Note that the units AND the leases (and the link between the two) will be described in the data communicated via the FIDJI format, so that the expert can work on the basis that suits him.

It should be read in this diagram that a building may have several leases, that each lease may have several income lines, and so on. The "valuation" corresponds to an element of the investor/owner's valuation plan (e.g. "valuation as at 31.12.2006"). A valuation will possibly include several appraisals (those of the expert(s)).

Other information may be added later in the file, such as electronic documents for example. From these data, the expert carries out his expertise. The expert will then complete the real estate file by adding his expertise to the valuation plan.

The comprehensive model of the FIDJI tree structure is represented, for a building in this general diagram:

[In red the new entities of version 3.0. In blue, the entities to which data was added].

Cette entité décrit une expertise immobilière effectuée sur un bien.

Elle récapitule les différentes méthodes de valorisation utilisées avec les résultats de chacune d’entre elles, ainsi que la valorisation finale retenue par l’expert.
Les intitulés des attributs reprennent le vocabulaire de la Charte de l’expertise en évaluation immobilière.

This entity describes the real estate valuation of a property.

It summarises the various appraisal methods used and the results of each one, as well as the final appraisal selected by the valuer.
The titles of the attributes are taken from the vocabulary of the Real Estate Valuation Charter.

Le bien (ou Asset) constitue un actif immobilier susceptible d’être acquis, vendu, délégué en gestion. Il s’agit du « conteneur » élémentaire dans le cadre des échanges de données immobilières (en dehors des tiers, qui peuvent également être transmis de manière indépendante)

Le BIEN tel qu’il est décrit correspond à un « immeuble physique ». Même si le bien du propriétaire ne comporte qu’un seul Lot, l’entité BIEN doit être présente en tant que telle et décrira l’immeuble qui aura une ou plusieurs occurrences de sous-entités décrivant les lots, les baux, etc.

A property (or asset) is a real estate asset that can be acquired, sold or whose management can be delegated. This is the basic "container" for property data exchanges (outside third parties, which can also be transmitted independently).

The PROPERTY as described corresponds to a "physical property". Even if the property owner has only one Lot, the PROPERTY entity must be present as such and describe the building that will have one or more occurrences of sub-entities describing units, leases, etc.