Sage ERP X3 : Pré et post-requis fonctionnels de migration d'un dossier en V6

Pré-requis au traitement de migration

On trouvera ci-dessous les pré-requis de migration d'un dossier. De façon générale, une première étape, qu'il est fortement conseillé de réaliser, est de vérifier la cohérence des données à migrer. En effet, sur un dossier qui a beaucoup de mouvements, et qui a parfois subi des étapes de maintenance, il est possible que certaines données ne soient pas parfaitement cohérentes (et ce d'autant plus que l'on peut avoir des développements spécifiques).

Cette opération permettra de détecter d'éventuels problèmes liés à des données qui risquent de provoquer des erreurs lors de la procédure de migration à proprement parler, obligeant à la relancer.

Il est aussi conseillé de purger un certain nombre de tables temporaires dont la migration peut être longue (par exemple la table des requêtes).

Paramétrage

Dossier

La législation en position '1' devient la législation de référence.

Table des adresses : ajout de champs dans la table BPADDRESS

• Le champ TEL de cette table est désormais dimensionné à 5. 5 champs sont maintenant disponibles : Téléphone, Fax, Numéro vert, Autre, Portable.
• Le champ WEB de cette table est désormais dimensionné également à 5. 5  champs sont maintenant disponibles : Email, Autre Email2, Autre Email3, Autre Email4 et Autre Email5.

Lors de la migration :

• Le numéro de téléphone de l'ancienne adresse n'est pas migré car il correspond à la dimension 0 (Téléphone) de la nouvelle liste de téléphones.
• Le fax (champ FAX) est transféré dans le champ TEL (dimension 1).
• Le portable (champ MOB) est transféré dans le champ TEL (dimension 4).
• L'Email de l'ancienne adresse n'est pas migré car il correspond à la dimension 0 de la nouvelle liste des Emails.

 Afin d'assurer une compatibilité avec les traitements et les états de la version 6, les anciens champs FAX et MOB ne sont pas supprimés et continuent à être alimentés jusqu'en version 7, avec les nouveaux champs : FAX = TEL(1) et MOB = TEL (4).

Modèles comptables

Dans le cas où l'utilisateur souhaite conserver ses montants en devise de reporting (champ AMTRPT en  V140 ou V5), il faut ajouter dans le modèle comptable de nouveaux référentiels automatiques liés aux référentiels social, analytique et IAS (champ Automatique à 'Oui'), et spécifier la devise de ces référentiels (= devise de reporting GSYSCUR des versions antérieures). La migration permet alors la récupération des montants reporting et ne modifie nullement les mouvements.

Algorithme de récupération du modèle comptable

Le traitement crée autant de modèles comptables qu'il y a de devises de sociétés différentes gérées dans le dossier migré V140 ou V5.
Les modèles des sociétés migrées sont créés à partir de la valeur du modèle définie dans le paramètre MIGGCM. Le code modèle créé dans le dossier migré reprend le code de la devise du référentiel général principal.

Lorsque le modèle comptable est déterminé :

• le référentiel IAS est supprimé si le code activité IAS n'est pas actif,
• les devises des trois premiers référentiels sont initialisés selon la devise de société.

Pièces automatiques / Groupes de pièces automatiques / Variables de pièces automatiques

Pour identifier et conserver la trace des spécificités des pièces automatiques du dossier client, lancez le traitement de comparaison de pièces automatiques entre les pièces du dossier à migrer et celles du dossier X3. En effet, lors de la migration, les pièces automatiques V6 sont rapatriées dans le dossier migré en écrasant celles d'origine de même code, qu'elles disposent d'un code activité ou non. Les spécificités de ces pièces doivent être reportées manuellement après migration sur la base du fichier trace de comparaison.

 
- Durant la migration, toutes les pièces automatiques du dossier de référence V6 sont rapatriées dans le dossier migré en écrasant celles existant sous un même code, qu'elles disposent ou non d'un code activité. Les spécificités client sont donc écrasées.
- Les pièces automatiques de codes différents de ceux du dossier de référence ne sont pas écrasées mais migrées telles quelles sans mise à jour, qu'elles disposent ou non d'un code activité.

Déclencheurs statistiques

Dans le traitement de migration, certains déclencheurs statistiques seront remplacés par ceux déjà existants dans le dossier migré. Pour éviter ce remplacement, un code activité spécifique doit leur être associé.

Codes statistiques écrasés en migration

Code	Intitulé	Nouveau lien
PID	Factures achat (détail)	CPTANALIN
PND	Retours (détail)	CPTANALIN
POD	Commandes achat (détail)	CPTANALIN
PSD	Demandes achat (détail)	CPTANALIN
PTD	Réceptions (détail)	CPTANALIN
SDD	Livraisons (détail)	CPTANALIN
SID	Factures vente (détail)	CPTANALIN
SOD	Commandes vente (détail)	CPTANALIN
SQD	Devis (détail)	CPTANALIN
SRD	Retours (détail)	CPTANALIN
GAS	Pièces comptables	GACM

Modèles d'import

Comptabilité et Comptabilité tiers

Tous les modèles d'import des modules Comptabilité et Comptabilité Tiers sont transférés du dossier X3 V6 dans le dossier migré.

Autres modules

Concernant les autres modules, certains modèles sont transférés, et d'autres créés.

Modèles d'import transférés :

• BPC* : table BPARTNER ajoutée,
• BPP*: table BPARTNER ajoutée,
• BPS*: table BPARTNER ajoutée,
• PIH* : structure modifiée,
• ITC : structure modifiée,
• ROU : structure modifiée.

Nouveaux modèles créés :

• BOMC : structure modifiée, 
• SIHIMPCAL : structure modifiée,
• SIHIMPNCAL : structure modifiée,
• PIHFL,
• PNH*,
• PNHFL,
• POHFL,
• PSHFL,
• PTHFL,
• SDHFL,
• SOHFL,
• SQHFL
• BOMS,
• CLL,
• CON,
• COT,
• ITC2,
• ITN,
• LDS,
• MST,
• OPP,
• PBL,
• QUE,
• RSE,
• SCS,
• SOL,
• SRE,
• TCK,
• TSK.
• BOMP : structure modifiée, 

Les modèles d'imports tableau sont mis à jour s'ils sont liés à un modèle d'import qui a été transféré.

 S'il le souhaite, l'utilisateur peut conserver ses anciens modèles d'import en affectant un code activité spécifique ou en dupliquant et renommant les modèles V140/V5. A défaut, ces anciens modèles seront perdus.

Règles de workflow

Les règles de workflow du dossier de référence V6 sont migrées dans le dossier d'exploitation et sont utiles aux demandes d'achat, commandes, commandes ouvertes et budgets opérationnels.
Liste des règles de workflow concernées :

• Signatures lignes demandes d'achats: PSDSIG, PSDSIGVAL, PSDSIGREJ, PSDSIGNOT, PSDSIGCAN, PSDSIGNCRPSD,
• Signatures commandes : POHSIG, POHSIGVAL, POHSIGREJ, POHSIGNOT, POHSIGCAN, POHSIGNCR,
• Signatures commandes ouvertes : POCSIG, POCSIGVAL, POCSIGREJ, POCSIGNOT, POCSIGCAN, POCSIGNCR,
• Budgets opérationnels : BUOAPP, BUOAPPREF, BUOAPPVAL, BUOREV, BUOREVREF, BUOREVVAL.

Tables

 Evitez de protéger des tables standard par un code activité. En effet, la structure d'une table protégée de la sorte ne sera pas mise à jour lors de la migration, et ceci peut provoquer des erreurs à la migration (l'affectation d'une valeur par défaut sur un champ nouveau, par exemple, va provoquer des erreurs, puisque le champ n'aura pas été créé).
Si vous avez des tables dans ce cas, vérifiez d'abord, via l'aide sur le dictionnaire des tables, si cette table a été mise à jour. Si c'est le cas, vérifiez si des champs ont été ajoutés, et rajoutez-les dans la table du dossier à migrer avant la migration. Si vous avez un doute, il est préférable de supprimer le code activité sur la table en question, et de protéger les champs spécifiques qui s'y trouvent.

• La table des régimes CEE TABEECSCH est migrée dans la table diverse n°15 et supprimée par la suite.
• La table DEBREGNAT du dossier de référence est migrée en partie. Les enregistrements du pays par défaut du dossier sont migrés et les valeurs de régimes et nature de ces enregistrements sont modifiés pour extraire le préfixe pays sur deux caractères.
• La table de détermination des taxes TABVAT dispose à présent d'une clé et plus d'une double entrée. Pour chaque entrée existant en V140/V5, un code générique est créé contenant le code régime et le niveau de taxe séparés par un "_". Le régime et le niveau de taxe sont conservés comme critères et le code taxe comme valeur liée aux critères.
• Les tables BPCUSTMVT et BPSUPMVT des encours clients et fournisseurs sont mises à jour à partir des documents non clos intervenant dans le calcul de l'encours.
  Les tables contenant les premiers et derniers documents sont mises à jour à partir des anciennes tables BPCUSTMVT et BPSUPMVT.
• La table des engagements est migrée sur le type de référentiel analytique principal du modèle comptable, que celui-ci soit coché 'Engagements' ou pas.

Tables diverses

• La table diverse 301 des catégories de sections analytiques est supprimée en version 6. Cette table doit donc comporter un code activité spécifique afin de ne pas être supprimée lors de la migration.
• Les codes d'enregistrement de la table diverse n°6 commençant par un zéro et supérieur à deux chiffres sont modifiés. Le zéro est supprimé et les tables liées sont mises à jour.

Business Intelligence

Lors de la migration, le système va supprimer tout le paramétrage et les états concernant la Business Intelligence de la version 5 pour les remplacer par le nouveau paramétrage. Les états développés en version 5 doivent être adaptés à la nouvelle structure.
L'environnement initial va être remplacé et il est donc nécessaire de le déplacer et sauvegarder. Le datawarehouse de la version 5 doit également être déplacé.

Paramétrages inter-sociétés

S'il existe une ligne de paramétrage sans société ni site précisés, il est nécessaire à présent de créer deux lignes de paramétrage : la première ligne doit être typée 'inter-société' et la deuxième ligne 'intra-société'.

Comptabilité

Fiche Compte

Les natures analytiques V140/V5, lors de la migration, sont transférées du compte analytique. La classification qui leur est attribuée correspond au premier caractère du code nature V140/V5. Dans le cas d'un plan de natures alphabétiques, il convient de mettre à jour les classes de comptes pour les comptes analytiques.

Avant la migration, dans le dossier V6 récepteur du dossier migré, dans le plan de comptes qui va recevoir les ex natures analytiques, il est indispensable de mettre à jour le tableau des classes de comptes par défaut, afin que celles-ci soient prises en compte lors de la migration.
Si cette mise à jour du tableau des classes par défaut n'est pas effectuée dans le dossier destination de la migration, Sage X3 affecte la dernière des classes de la législation des classes du plan.

La recherche de la classe des comptes pour les comptes analytiques se fait de cette façon :

• si la racine du compte analytique est définie sous le code plan, les préfixes sont recherchés,
• si la racine du compte analytique n'est pas définie sous le code plan mais qu'il y a d'autres racines, la dernière racine est prise en compte,
• si aucune racine de comptes n'est définie sous le code plan, la dernière racine de la « Législation classes » (donnée obligatoire sous le code plan) est prise en compte.

Cet algorithme est aussi applicable pour les groupes de comptes analytiques : s'il y a des pyramides sur les natures V5, elles deviennent des pyramides de comptes analytiques.

Lettrage et pièces comptables

 Aucun lettrage ne doit être en cours. La table Lettrage batch doit être vide.
Aucune pièce comptable ne doit être en cours de validation. Les tables GACCTMP/ GACCTMPA/ GACCTMPD et GACIASTMP/GACIASTMPD doivent être vides.

Journaux

Tous les journaux doivent être re-ouverts, pour toutes les sociétés.

Fin d'exercice

Si une société a plus de deux exercices ouverts par rapport à la date système et le paramètre FRADGI positionné sur 'Oui', il est préférable de clore les exercices au delà du second avant la migration.
Dans le cas contraire, le message non bloquant "Pas plus de deux exercices ouverts" signale l'anomalie lors de la migration. Aucun nouvel exercice ne pourra être ouvert sans clôture de l'arriéré.

Engagements

Les engagements (fonction Engagements utilisant les tables GCOMMIT et GCOMMITD) sont migrés sur le type de référentiel analytique principal du modèle comptable, que celui-ci soit coché 'Engagements' ou pas.

Négoce

Factures ventes / achats

• La modification des structures au niveau des pieds de factures nécessite la validation des factures ventes et achats.
• Le format est ajouté pour chacune des colonnes des structures de tarifs ventes et achats :
• [F:TCU]CURFMT2 pour les montants,
• 3.2# pour les pourcentages.
• Initialisation du code adresse payé/facturant sur les documents d'achats : si le tiers payé/fournisseur facturant du document est le même tiers payé/fournisseur facturant renseigné sur la fiche du tiers du mouvement alors le code adresse par défaut est celui du tiers payé/fournisseur facturant de la fiche du fournisseur du mouvement.
  Si le tiers est différent, l'adresse par défaut du tiers payé/fournisseur facturant du document est reprise.
• initialisation du code payeur factures ventes : si le tiers payeur de la facture de ventes est le même tiers payeur renseigné sur la fiche du client facturé alors le code adresse par défaut est celui du tiers payeur de la fiche du client facturé.
  Si le tiers payeur est différent, l'adresse par défaut du tiers payeur de la facture est reprise.

Eléments de facturation

• Prise en compte de la DEB : si le code activité DEB est actif, les éléments de facturation impactent la valeur fiscale.
• Règles d'éclatement : pour tous les éléments de facturation les règles d'éclatement sont initialisées de la façon suivante :
  

  Origine	Destination	Règles d'éclatement
  Devis	Commande	Toutes les commandes
  Commandes	Factures de commandes	Suit la règle V140/V5 'Transfert cde fac' paramétrée sur le dossier d'origine
  Commandes	Livraisons	Suit la règle V140/V5 'Transfert cde liv' paramétrée sur le dossier d'origine
  Livraison	Factures	1ère facture : une livraison n'est jamais éclatée sur plusieurs factures (la migration est seulement possible sur une facture)
  Facture	Avoir	Tous les avoirs

• Règles de regroupement : la règle de regroupement est positionnée sur 'Oui', quel que soit l'élément de facturation.
• pour les éléments de facturation en montant, la valeur de la règle de regroupement est 'Somme des montants',
• pour les éléments de facturation en pourcentage, la valeur de la règle de regroupement est '1er document'.

Tiers

• Chaque rôle de tiers dispose maintenant d'un code adresse par défaut initialisé par le code adresse par défaut du tiers associé.
• Chaque rôle de tiers dispose maintenant d'un contact par défaut initialisé par le contact par défaut du tiers associé.
• Chaque rôle de tiers bénéficiant d'un code devise dispose maintenant d'un code devise par défaut initialisé par le code devise par défaut du tiers associé.
• Le 'client livré' par défaut correspond à l'adresse par défaut du client s'il s'agit d'une adresse de livraison. Dans le cas où il ne s'agit pas d'une adresse de livraison, le client livré par défaut est initialisé par la première adresse rencontrée.
• Le code adresse par défaut du fournisseur initialise le code adresse d'expédition du fournisseur en en-tête de commande ou de réception.
  Pour les tiers divers, l'adresse de commande est reprise.

Fiche client

Le tiers risque de la fiche client est alimenté par le client facturé de la fiche client.
Le code adresse du tiers payeur est initialisé par le code adresse par défaut du tiers payeur.

Fiche fournisseur

• Le tiers risque de la fiche fournisseur est alimenté par le fournisseur défini dans le paramètre INIBPRRSK, c'est-à-dire le tiers payeur de la fiche fournisseur.
  Le code adresse du tiers payé et du fournisseur facturant sont initialisés par le code adresse par défaut du fournisseur facturant et du tiers payeur.

Immobilisations

• La migration est à réaliser obligatoirement après une clôture périodique ou exercice.

Impacts sur la comptabilité

• Les dotations périodiques comptabilisées sur l'exercice en cours ne peuvent être reprises. Les pièces correspondantes doivent être extournées dans la comptabilité Sage ERP X3 V6.
   
• En revanche, les pièces enregistrées à l'occasion des cessions ou des mises au rebut d'immobilisations sur l'exercice en cours ne doivent pas être extournées dans la comptabilité X3, sauf les éventuelles pièces de complément de dotation générées par ces sorties.
   
• Si des virements d'immobilisations de type "Changement de nature" ou "Correction d'erreur" ont été effectués sur l'exercice en cours, les éventuelles pièces de complément de dotation correspondantes doivent être extournées dans la comptabilité X3. De plus, des OD manuelles doivent être passées pour virer ce montant de dotation, du compte d'amortissement après virement (Crédit), au compte d'amortissement avant virement (Débit).
   
• Les éventuelles pièces de simulation issues de la gestion des immobilisations (dotations, mises au rebut et réévaluations) doivent aussi être extournées dans la comptabilité X3.

Post-requis au traitement de migration

Paramétrage

Pièces automatiques / Groupes de pièces automatiques / Variables de pièces automatiques

Les pièces automatiques disposant de codes différents de celles du dossier X3 V6 sont migrées sans adaptation. Il est conseillé de dupliquer les pièces automatiques standards et de les mettre à jour suivant les spécificités client, plutôt que de les adapter.
Ces spécificités doivent être reportées manuellement en utilisant la trace issue de la comparaison demandée (cf Pré-requis). 
Un contrôle doit être réalisé sur l'existence et le contenu des formules mises en oeuvre dans les pièces automatiques, ces dernières faisant appel à des types de pièces et des journaux référencés dans leur dossier. En effet, les formules du dossier de référence V6 (dont certaines existent seulement depuis la V6) ne sont pas rappatriées lors de la migration.
 

Règles de workflow

La présence des règles de workflow suivantes doit être vérifiée :

• Signatures lignes demandes d'achats: PSDSIG, PSDSIGVAL, PSDSIGREJ, PSDSIGNOT, PSDSIGCAN, PSDSIGNCRPSD,
• Signatures commandes : POHSIG, POHSIGVAL, POHSIGREJ, POHSIGNOT, POHSIGCAN, POHSIGNCR,
• Signatures commandes ouvertes : POCSIG, POCSIGVAL, POCSIGREJ, POCSIGNOT, POCSIGCAN, POCSIGNCR,
• Budgets opérationnels : BUOAPP, BUOAPPREF, BUOAPPVAL, BUOREV, BUOREVREF, BUOREVVAL.

Règles d'affectation

Les règles de signatures achats V140/V5 pour chaque type de document et société doivent avoir été générées dans les règles d'affectation.

Tables

Il est important de vérifier que toutes les règles de détermination des taxes sont migrées.

Etats négoce et comptabilité

Pour les états à destination des tiers, les personnalisations effectuées doivent être reportées dans les nouveaux états livrés qui tiennent compte des modifications structurelles de la V6.

Personnalisation des objets

Les sélections liées à la personnalisation des objets doivent être vérifiées.

Comptabilité

• Exécuter la resynchronisation de toutes les balances.
• Exécuter la resynchronisation des soldes comptables.
• Relancer l'extraction de la balance consolidée.
• Exécuter la resynchronisation des pyramides.
• Réactualiser le paramétrage des écrans de consultations (comptabilité générale et comptabilité tiers) pour tenir compte de la nouvelle structure.
• Mettre à jour les classes de comptes sous les Comptes Analytiques et Groupes de comptes analytiques.
• Vérifier et mettre à jour les déclencheurs statistiques sur les écritures (cette table est en copie automatique).
• Réviser le paramétrage des tableaux de bord liés à l’IAS. Si des expressions comportaient des syntaxes de comptes généraux, ces expressions sont à revoir manuellement.
• Renseigner la valeur des paramètres GTECLO(xx) et GTEFRW(xx) (CPT/FIY) suite à la migration, afin que la prochaine fin d'exercice aboutisse.

Négoce

Devis

Les devis validés ou non totalement commandés sont valorisés pour stocker le résultat dans les nouvelles tables 'Documents ventes - taxes' (PVCRVAT)  et 'Documents ventes - élément pied' (PVCRFOOT).
Les devis non validés ou totalement commandés ne sont pas revalorisés et ne bénéficient d'aucun enregistrement dans les tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Commandes d'achats

Toutes les commandes sont recalculées. Ceci entraîne une alimentation des nouveaux champs de l'onglet "Lignes" et une alimentation des tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Commandes ventes

Les commandes non soldées sont valorisés pour stocker le résultat dans les nouvelles tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.
Les commandes soldées ne sont pas revalorisés et ne bénéficient pas d'enregistrement dans les nouvelles tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Réceptions d'achats

Toutes les réceptions sont recalculées. Ceci entraîne une alimentation des nouveaux champs de l'onglet "Lignes" et une alimentation des tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Livraisons

Les livraisons non validées ou validées mais non facturées sont valorisés pour stocker le résultat dans les nouvelles tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.
Les livraisons facturées ne sont pas revalorisés et ne bénéficient pas d'enregistrement dans les nouvelles tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Factures d'achats

Les factures d'achats ne sont pas recalculées. Les informations du pied de factures sont directement transmises dans les nouvelles tables 'Documents ventes - taxes' et 'Documents ventes - élément pied'.

Factures de ventes

Les factures doivent toutes être validées et ne sont donc pas revalorisées.
Les tables 'Documents ventes - taxes' et 'Documents ventes - élément pied' sont initialisées à partir de la table 'Facture vente valorisation'.
Pour les éléments de facturation en 'Taux fixe', la taxe figurera dans la table 'Documents ventes - élément pied'  au niveau des champs DTANET, DTAVAT, DTAVATRAT et DTAVATAMT.
Pour les éléments de facturation en taux 'Produit', la taxe ne figurera pas dans les champs dimensionnés de la table 'Documents ventes - élément pied' (DTANET, DTAVAT, DTARATVAT et DTAVATAMT).

Documents négoce

Dans tous les documents négoces, les informations analytiques des lignes de documents sont toutes stockées dans la table des lignes comptables analytiques (CPTANALIN).

Régularisations de sorties

Dans le cas où les régularisations de sorties sont activées après la migration d'un dossier 140 vers un dossier V6, le statut stock des périodes précédent la migration doit être spécifié comme 'Interdit'. En effet, la régularisation de sortie ne fonctionne pas sur les enregistrements créés en version 140 ce qui risque de générer des erreurs dans le recalcul des mouvements de sorties antérieurs à la migration.

Déclaration d'échanges de biens

La Déclaration d'Echanges de Biens s'appuie sur tous les flux physiques enregistrés et plus uniquement sur les factures. Après la migration et avant de lancer toute nouvelle génération de fichier DEB, il faut solder les mouvements physiques non déclarés mais antérieurs à la date de la dernière déclaration ; pour cela, il est nécessaire de relancer la déclaration pour marquer les flux ne devant pas être pris en compte.
Une regénération des lignes traitées pour la période précédente peut être lancée dès que celle-ci a déjà été adressée aux douanes.
Pour conserver la trace des mouvements déclarés aux douanes, une sauvegarde de la table DEB doit être réalisée au préalable.

Gestion de production

Dans la fonction des paramètres d'agrégation comptable, tous les paramètres d'agrégation faisant référence au numéro d'ordre de fabrication ([F:MWI]MFGNUM) doivent être mis à jour avec la clé [F:MWI]VCRNUM.

Immobilisations

Familles

Les Familles créées automatiquement à partir des catégories / sous-catégories sont à vérifier.

Associations de rubriques

Les associations de rubriques par Famille créées automatiquement par défaut sont à vérifier/compléter et doivent être activées pour être appliquées. Les règles de création de ces associations sont données ci-dessous.

Immobilisations : règles de migration

Mise à jour avant migration

Certaines abréviations sont changées afin d'éviter des doublons :

• La table V5 : CDIADSPSCT [F:CDS] change d'abréviation et devient [F:CD2] dans Sage ERP V6
• La table V5 : FIXASSET [F:FAS] change d'abréviation et devient [F:FA2] dans Sage ERP V6
• La table V5 : FAS change de nom et devient FAZ dans Sage ERP V6
  

Avant la migration des immobilisations, le traitement procède à la création automatique des tables diverses suivantes, dans le dossier ERP V6 : 

• Table diverse 540 contenant les Sociétés du dossier migré V5, possédant des immobilisations.
• Table diverse 591 contenant la correspondance Type d'amortissement du dossier V5 - Plan d'amortissement du dossier V6. Voir Table de correspondance ci-dessous.
• Table diverse 611 contenant les Familles comptables alimentées à partir des informations Catégorie/Sous-cétégorie du module Immobilisations V5.

Opérations effectuées automatiquement lors de la migration

Pour chaque société présente dans la table diverse 540 :

Création du contexte Comptable et fiscal : alimentation des tables CONTEXT et FISCYEAR

• A chaque Type d'amortissement V5 va correspondre un Plan d'amortissement V6 défini dans le contexte Comptable et fiscal. Voir Table de correspondance ci-dessous.
• Le découpage des exercices et contextes est basé sur le découpage des exercices/périodes comptables définis pour la société traitée.
• Par convention, le 1er exercice ouvert pour la société du dossier V5 sera l'exercice courant du contexte Comptable et fiscal du dossier V6.
• Par convention, la 1ère période ouverte du 1er exercice ouvert pour la société du dossier V5 sera la période courante du contexte Comptable et fiscal du dossier V6.

Création d'Associations par défaut

En V5, les tables FISCAT et FISCATDEP contiennent les différentes catégories et sous-catégories d'immobilisations ainsi que les méthodes d'amortissement et codes comptables associés.

Une correspondance entre ces catégories et sous-catégories et les codes Familles V6 permet la création automatique d'associations, pour chaque société migrée.

Un paramétrage de définition d'association par Famille est automatiquement créé au niveau Par défaut, avec les valeurs indiquées ci-dessous. L'utilisateur peut les modifier.

Modèle comptable : modèle comptable de la société
Objet métier : Bien comptable
Déterminant : Famille comptable alimentée à partir de la Catégorie et sous-catégorie
Indicateur Actif : Actif

Règles d'alimentation, par le biais de cette association, des valeurs du bien et de ses plans d'amortissements :

Rubrique	Intitulé	valeur/défaut	Origine V5
AASTYP	Type d'immobilisation
ACCCOD	Code comptable
CMPSTA	Statut du bien	1=Autonome
STABILTYP	Type de stabilité	1=Fixe
TAXTYP	Type taxes locales		Interprétation de PTA (taxe foncière) et TIT (taxe professionnelle)
ADMCOE	Coefficient admission	----------	----------
USRFLDA	Code libre	----------	----------
DPRPLN	Plan d'amortissement		DEFTYP [FCD]
DPM	Mode d'amortissement		WROMOD [FCD] Voir Table de correspondance ci-dessous
DPRDUR	Durée d'amortissement		YEANBR [FCD]
DPRRAT	Taux d'amortissement		DEPRAT [FCD]
ALWCOD	Règle particulière	----------	----------
CRBVEHCOD	Plafond véhicule	----------	----------
DPRRAT2	Taux amt exceptionnel	----------	----------
PRATYP	Type prorata		RNDTYP [FCD]
ACLCOE	Coef. accélération	----------	----------

Migration des immobilisations

Sélection des immobilisations à migrer :

Les immobilisations ayant un état Inactif (STA=2) ne sont pas prises en compte dans la migration.

Alimentation des champs de la table des biens FIXDASSET dans le dossier V6 à partir des champs du dossier V5 :

Désignation	Champs V6 de FIXDASSET	Champs V5	Note
Société	CPY	CPY
Site financier	FCY	FINFCY
Référence bien	AASREF	FASCOD_FASNUM
Désignation 1	AASDES1	DES
Désignation 2	AASDES2	DESSUP(0)
Ensemble	SET	FASREF si renseigné, FASCOD sinon
Famille	ACGGRP	CAT SUBCAT	1
Code comptable	ACCCOD	ACCCOD
Date achat	PURDAT	PURDAT
Date imputation comptable	AASIPTDAT	PURDAT
Date mise en service	ITSDAT	ACTDAT
Type de détention	OWNTYP	Valeur = 1 : En propriété
Nature entrée (Etat à l'achat)	PURNAT	TYPRCP	2
Quantité	AASQTY	QTY	3
Type d'immobilisation	AASTYP	FASTYP	4
Base Taxe professionnelle	TAXBAS	BASTAX
Type taxe	TAXTYP	Interprétation de PTA (taxe foncière) et TIT (taxe professionnelle)	5
Site géographique	GEOFCY	FCY	6
Bâtiment	LOC	PLC1	7
Répartition analytique	DSP	DSP
Montant achat HT	ACGETRNOT	TOTAMTNOT	8
Taux TVA facturée	IVCVATRAT	à calculer	9
Montant TVA facturée	IVCVATAMT	(TOTAMTATI - TOTAMTNOT)	10
Flag forçage TVA facturée	IVCVATFLG	Forcé
Taux TVA récupérée	DEDVATRAT	A calculer
Montant TVA récupérée	DEDVATAMTA	(TOTAMTATI - AMTORI)	11
Flag forçage TVA récupérée	DEDVATFLG	Forcé
Coefficient assujettissement	ASJCOE	1
Coefficient taxation	TAXCOE	1
Coefficient admission	ADMCOE	1
Coefficient déduction	DEDCOE	1
Sections Axe Analytique 1 à 9	CCE (0) à (9)	CCE (0) à (9)
Date de sortie	ISSDAT	SALDAT
Type de sortie	ISSTYP	Interprétation de SALREN / DILREN	12
Montant de sortie	ISSAMT	SALPRI
Acheteur	BUY	BPC
Montant +/- value comptable	GAL(0)	SALVAL
Montant TVA déduction complémentaire	VATREGDED	AMTVATRMN
Motif réévaluation	RVACMT	RVAREN
Bureau	USRFLDA1	PCL2	13
Localisation	USRFLDA2	PCL3	13
Ccode postal	USRFLDA3	POSCOD	13
Numéro de série	USRFLDA4	SERNUM	13

Notes :
 
1 - La Famille est formatée sur le modèle 000c000s.
2 - Voir Table de correspondance ci-dessous.
3 - Si 0, c'est la valeur 1 qui est mise en place.
4 - Voir Table de correspondance ci-dessous.
5 - Si TIT (taxe prof.) = oui, alors TAXTYP = BNPTF  
     Si PTA (taxe foncière) = oui, alors TAXTYP = BPTF
     Sinon, TAXTYP = Hors champ
6 - Egal au site financier si non renseigné.
7 - Construit à partir du site géographique et du bâtiment avec un étage à X et une pièce à X. Création automatique du bâtiment dans la table diverse 404 et de la localisation si besoin. De la forme SITE/BAT/XX.
8 - Si TOTAMTNOT est nul ou est égal à TOTAMTATI, c'est AMTORI qui est pris.
9 - Les taux sont exportés sous la forme 0.196.
10 - Nul si TOTAMTNOT est nul.
11 - Nul si TOTAMTNOT est nul, (TOTAMTATI - TOTAMTNOT) si AMTORI < TOTAMTATI ou si AMTORI < TOTAMTNOT).
12 - ISSTYP prend la valeur 1 - Vente si SALREN (Motif cession) est alimentée (quelle que soit sa valeur). ISSTYP prend la valeur 2 - Rebut si DILREN (Motif mise au rebut) est alimentée (quelle que soit sa valeur).
13 - Les valeurs sont stockées dans la table diverse associée à la zone libre.

Alimentation des plans d'amortissement (DEPREC) dans le dossier V6 à partir des champs du dossier V5 :

Désignation	Champs V6 de DEPREC	Champs V5	Note
Plan d'amortissement	DPRPLN (*)	DEPTYP de FIXDEP	1
Mode d'amortissement comptable	DPM (*)	WROMOD de FIXDEP en fonction de DEPTYP	1
Durée d'amortissement comptable	DPRDUR (*)	YEANBR de FIXDEP en fonction de DEPTYP	2
Taux d'amortissement comptable	DPRRAT (*)	DEPRAT de FIXDEP en fonction de DEPTYP
Coefficient d'accélération	ACLCOE (*)	1
Type de prorata temporis	PRATYP (*)	En fonction de RNDTYP de FIXDEP
Date début amortissement comptable	STRDPRDAT (*)	DEPDAT de FIXASSET
Montant réévalué	DPRBAS (*)	AMTRVA
Valeur résiduelle	RSDVAL (*)	RSDVAL de FIXASSET
Valeur d'amortissement	DPRVAL (*)	AMTORI de FIXASSET
Règle particulière	ALWCOD (*)	1
Véhicule	CRBVEHCOD (*)
Devise	CUR (*)	Devise du contexte
Base d'amortissement comptable	BSEVAL (*)	AMTDEP
Cumul amortissement comptable	DPRCUM (*)	Cumul fin d'exercice précédent (calculé à partir de FIXWRO)
Dotation amortisseemnt comptable	ENDDPE (*)	Dotation comptabilisée de l'exercice en cours (calculée à partir de FIXWRO)	3
Type de prorata temporis	PRATYP (*)	En fonction de RNDTYP de FIXDEP
Montant de réévluation	RVAAMT (*)	AMTREV de FIXWRO
Date début exercice	FIYSTRDAT (*)	FIYSTR de FISCALYEAR
Date fin exercice	FIYENDDAT (*)	FIYEND de FISCALYEAR
Statut période	DEPSTA
Date début période	PERSTRDAT (*)	PERSTR de FISCALYEAR
Date fin période	PERENDDAT (*)	PEREND de FISCALYEAR
Indicateur Migration	FLGSIM (*)	2 = Oui

(*) = : (0) pour le plan Comptable, (1) pour le plan Fiscal, (2), (3)...  pour les plans autres.
 
Notes :
 
1 - Voir Table de correspondance ci-dessous.
2 - Possibilité de décimales (années et centièmes d'années. Exemple : 6,66).
3 - Cette colonne n'est alimentée que pour les immobilisations cédées ou rebutées dans l'exercice en cours. Elle est reprise en "Dotation forcée" dans Sage ERP X3 V6, de façon à ne pas être recalculée. Cette dotation forcée est par contre prise en compte dans les écritures comptables de dotation générées par Sage ERP X3 V6 car elle a été extournée dans X3 V5. Ainsi, les écritures de sortie d'actif passées dans X3 V5 restent correctes.

Tables de correspondance

Table de correspondance : Type d'entrée du bien (TYPRCP) V5 --> Etat à l'achat (PURNAT) V6

V5  TYPRCP ADI 318	V6 PURNAT ML 3152
F - Fusion	2 - Occasion
L - Livraison à soi-même	1 - Neuf
N - Neuf	1 - Neuf
O - Occasion	2 - Occasion

Table de correspondance : Type d'immobilisation (FASTYP) V5 --> Type d'immobilisation (AASTYP) V6

V5  FASTYP ML 806	V6 AASTYP ML 3151
1 - Incorporelle	2 - Incorporelle
2 - Corporelle	1 - Corporelle
3 - En cours	1 - Corporelle
4 - Participations	3 - Goodwill
5 - Financier	4 - Financière

Table de correspondance : Mode d'amortissement V5 --> Mode d'amortissement V6

V5  Mode amortissement	V6  Mode amortissement
C = Croissant	PR= Progressif
D = Dégressif	DF = Dégressif français
E = Croissant	SO = Softy
L = Linéaire	LP = Linéaire
M = Manuel	SA= Sans amortissement
N = Non amorti ou autre	SA= Sans amortissement

Table de correspondance : Type d'amortissement X3 V5 --> Plan d'amortissement V6

X3 V5 (TDI 312)	X3 V6 (TDI 591)	V6
Type d'immobilisation	Plan d'amortissement	Contexte
E Economique	1  Comptable	1 = Comptable et Fiscal
F Fiscal	2  Fiscal	1 = Comptable et Fiscal
T Technique	10 Libre 1	1 = Comptable et Fiscal
Autre ...	11 Libre 2	1 = Comptable et Fiscal